DEP-2025 Practice Questions

A one-to-one deployment is a fundamental model where a single device is assigned to an individual user. This model is a primary consideration in establishing device management goals because it directly influences policies for personalization, security, app distribution, and data management. It is distinct from other models, such as shared device deployments, where multiple users access the same device. The choice of deployment model is a strategic decision that precedes technical implementation steps like enrollment.

A. An Application Programming Interface (API) is a set of protocols for building and integrating application software; it is a technical tool, not a device assignment strategy.

B. Over-the-air (OTA) enrollment is a technical method used to enroll devices into a Mobile Device Management (MDM) solution, not the strategic deployment model itself.

1. Apple Inc.

"Apple Platform Deployment

" Apple Support

20 Sep 2023. In the section "Choose a deployment model

" the guide explicitly defines and contrasts "One-to-one deployment" and "Shared deployment" as the primary models to consider. It states

"The first decision is to choose a deployment model... In a one-to-one deployment

the user is the primary person using the device." (Section: Plan for deployment > Choose a deployment model).

2. Apple Inc.

"Intro to Apple device deployment

" Apple Support

20 Sep 2023. This introductory guide outlines the core concepts of deployment

emphasizing the need to first define goals and choose a model like one-to-one before proceeding with technical steps. (Section: Deployment and management overview).

Cryptographic separation of organizational and personal data on iPhones and iPads is the core feature of the User Enrollment management mode, designed for Bring Your Own Device (BYOD) scenarios. This separation is achieved by creating a dedicated, cryptographically-sealed Apple File System (APFS) volume for managed apps and data.

There are two primary methods to initiate User Enrollment:

1. Account-driven User Enrollment (A): A modern method where the user signs into a Managed Apple ID directly within the Settings app.

2. Profile-based Enrollment: A traditional method where the user downloads an enrollment profile from a web portal. Option (E) represents this mechanism. When an MDM solution directs this process for a personal device, it triggers User Enrollment, resulting in the required data separation.

B. Account-driven Device Enrollment: This is for fully managing an organization-owned device and does not create a separate volume for personal data.

C. Authenticated Enrollment: This describes a process step (authentication) common to many enrollment methods, not a distinct enrollment type that defines data management.

D. Automated Device Enrollment: This provides the highest level of supervision for organization-owned devices, managing the entire device without cryptographic data separation.

1. Apple Platform Deployment (Fall 2023)

"User Enrollment and MDM" section: "To help ensure this separation

User Enrollment establishes a separate Apple File System (APFS) volume on the device for managed data... This separation is secured cryptographically

using a separate set of encryption keys from the ones used for user data."

2. Apple Platform Deployment (Fall 2023)

"Choosing an enrollment method" section: This section details the different enrollment paths. It explicitly lists the two methods that lead to User Enrollment: "Account Driven User Enrollment" and "Profile Based User Enrollment

" which correspond directly to the logic for selecting options A and E.

3. Apple Platform Deployment (Fall 2023)

"How User Enrollment works" section: "User Enrollment requires a Managed Apple ID... This Managed Apple ID is on the same partition as the user’s personal Apple ID

but is in a separate APFS volume created at enrollment." This confirms the underlying technology that provides the cryptographic separation.

The Custom App distribution model is designed for private, business-to-business deployment. After an app is submitted and approved through App Store Connect, the developer must explicitly make it available to specific organizations. This is accomplished by the developer entering the organization's name and Organization ID within App Store Connect. This action assigns the app to the designated Apple Business Manager account, making it visible and available for license acquisition and distribution by that specific organization. This step is the critical link between the developer and the purchasing organization for private distribution.

A. App submissions are managed through the App Store Connect review process, not AppleCare, which is Apple's support service.

B. While all apps must be signed, this is a general development requirement, not the specific action that enables distribution to a particular organization.

D. AppleCare is a support channel and is not involved in the operational process of assigning apps to organizations.

1. Apple Developer Documentation

"Distributing Custom Apps." This document outlines the entire process and explicitly states: "In App Store Connect

you’ll select the organizations who can download your app on Apple Business Manager or Apple School Manager. You’ll need their Organization ID and organization name." This directly confirms that the developer assigns the app. (See the section "Make your app available privately").

2. Apple Business Manager User Guide

"Intro to custom apps." This guide explains the process from the organization's perspective: "After a developer makes a custom app available to your organization

a content manager with the appropriate privileges can find the app in the Custom Apps section of the Apps and Books sidebar." This confirms the prerequisite action is taken by the developer. (See Section: "How custom apps work").

3. Stanford University

IT Services

"Distribute Custom iOS Apps." The university's documentation for its developers clarifies the workflow: "The developer will need your Organization Information... to make the app available to Stanford in the VPP/B2B App Store... Once the developer has submitted the app and made it available to Stanford

you will be able to 'purchase' free licenses..." This corroborates the developer-led assignment process. (See Section: "Requesting a Custom B2B App").

The ability to purchase content, such as books and apps, within Apple School Manager is governed by a system of role-based permissions. The Administrator role has the highest level of privileges and can perform all tasks, including buying content licenses for the entire organization. While the Content Manager role is also specifically designed for this task, the Administrator role is a valid and sufficient requirement for purchasing books. The action is tied to the permissions of the role assigned to a user's Managed Apple ID, not the ID itself.

B. An Apple Developer account: This account is for creating and publishing applications on the App Store, not for purchasing content within an educational or enterprise management environment like Apple School Manager.

C. A Managed Apple ID: While an Administrator uses a Managed Apple ID to sign in, the ID itself does not grant purchasing rights. The specific role assigned to that ID determines the user's permissions.

D. User acceptance: This is a step that may occur on the end-user's device after a book license has been purchased by an administrator and assigned to them. It is not a prerequisite for the purchase itself.

1. Apple Inc.

Apple School Manager User Guide. "Intro to roles and privileges in Apple School Manager". This section details the capabilities of each role

explicitly stating that the Administrator "can also perform all the tasks of any other role

" which includes the content purchasing duties of a Content Manager.

2. Apple Inc.

Apple School Manager User Guide. "Buy apps and books in Apple School Manager". This section outlines the process for purchasing content

a task performed by users with appropriate administrative privileges (Administrator or Content Manager).

3. Stanford University IT Services

Apple Device Management: Overview. "Service Details" section. University documentation on their Apple management service describes how administrators use Apple School Manager for institutional purchasing of apps and books

reinforcing that this is an administrative function.

Shared iPad is a feature designed for educational and business environments, allowing multiple users to use the same iPad while keeping their data and settings separate. This functionality is exclusively enabled through Managed Apple IDs. These special accounts are created, owned, and managed by an organization through Apple School Manager or Apple Business Manager. When a user signs in to a Shared iPad with their Managed Apple ID, their personalized environment, including iCloud data and app data, is loaded onto the device for their session. Personal Apple IDs cannot be used as they are not controlled by the organization's management framework.

A. Apple ID: This term is too general. Shared iPad requires the specific managed type of Apple ID, not any generic Apple ID.

C. Personal Apple ID: These are user-owned accounts and are not integrated with the organizational management infrastructure required for Shared iPad.

D. Shared Apple ID: This is not an official type of Apple account. The feature's name refers to a shared device, not a shared account.

1. Apple Inc. (2024). Apple Platform Deployment Guide. "Shared iPad requirements". Retrieved from Apple's official documentation website. This section explicitly lists "Managed Apple IDs owned by the organization" as a primary requirement for implementing Shared iPad.

2. Apple Inc. (2024). Apple School Manager User Guide. "Intro to Managed Apple IDs for institutions". This guide details that Managed Apple IDs are essential for accessing Apple services in an educational context

including signing in to Shared iPad.

3. Apple Inc. (2024). Apple Business Manager User Guide. "What are Managed Apple IDs in Apple Business Manager?". This document clarifies that Managed Apple IDs are designed for business use and are required for features like Shared iPad to ensure organizational control and data segregation.

Shared iPad is a specific deployment mode for institutionally-owned devices that requires a Mobile Device Management (MDM) solution. The MDM server is responsible for sending the configuration profile that enables Shared iPad mode on a supervised device. It also integrates with Apple School Manager or Apple Business Manager to manage the required Managed Apple IDs, allocate storage for user partitions, and handle the caching and syncing of user data. Without an MDM solution that explicitly supports this feature, it is not possible to configure, deploy, or manage Shared iPad.

B. Apple Configurator: While Apple Configurator can prepare devices for MDM enrollment, it is not the management framework required for the ongoing operation and user session management of Shared iPad.

C. User Enrollment: This is an MDM enrollment type for personally-owned (BYOD) devices and is incompatible with the device-centric, supervised model required for Shared iPad.

D. A VPN configuration: A VPN provides secure network access and is not a foundational requirement for enabling the core functionality of Shared iPad itself.

1. Apple Platform Deployment Guide: In the section "Shared iPad requirements

" the first listed requirement is "An MDM solution that supports Shared iPad." This document further details that the MDM solution handles the deployment of the configuration profile to enable the feature. (Source: Apple Platform Deployment

"Shared iPad requirements

" published October 23

2023).

2. Apple School Manager User Guide: The guide states

"You can use Apple School Manager with your mobile device management (MDM) solution to configure Shared iPad." This highlights the essential link between the Apple service and the MDM for setup. (Source: Apple School Manager User Guide

"Intro to Shared iPad with Apple School Manager

" Section: "Shared iPad and MDM

" published December 12

2023).

3. Apple Developer Documentation: The MDM protocol includes a specific SharedDeviceConfiguration payload. The existence and detailed specification of this payload confirm that MDM is the exclusive

programmatic method for enabling and configuring Shared iPad. (Source: Apple Developer Documentation

Device Management > MDM > Payloads > com.apple.shareddeviceconfiguration).

To manage an Apple device with a Mobile Device Management (MDM) solution, an enrollment profile must be installed. This profile is a specific type of configuration profile containing an MDM payload. The payload includes the server URL and other necessary information that directs the device to communicate with the MDM server. The installation of this profile initiates the enrollment process, establishing a trusted relationship and allowing the server to send commands and configurations to the device.

A. A provisioning profile: This is incorrect because provisioning profiles are used by developers to permit an app to be installed on specific devices and to use certain services like Push Notifications or iCloud.

B. A supervision identity: This is incorrect because a supervision identity is a certificate stored on a Mac running Apple Configurator, used to establish ownership and control over a device, not installed on the device itself for enrollment.

D. Apple Configurator: This is incorrect because Apple Configurator is a macOS application used to manually configure and enroll devices; it is not installed on the managed iOS, iPadOS, or tvOS device.

1. Apple Inc.

"Apple Platform Deployment

" Intro to mobile device management

(Nov 2023). In the "How mobile device management works" section

it states

"The process starts by installing an enrollment profile

which can be done by the user or automatically."

2. Apple Inc.

"Apple Platform Deployment

" Choose an MDM enrollment method

(Nov 2023). This guide details that all methods—User Enrollment

Device Enrollment

and Automated Device Enrollment—rely on the installation of an enrollment profile to link the device to an MDM server.

3. Apple Developer Documentation

"MDM Protocol

" Device enrollment. The documentation specifies that MDM enrollment is initiated when the device receives and installs a configuration profile containing an MDM payload.

Supervision is a mode designed for institutionally-owned Apple devices that provides organizations with a higher level of management control. Its primary benefit is unlocking an extensive set of additional configuration profiles and restrictions that are unavailable on non-supervised devices. This allows administrators to enforce stricter security policies, silently manage applications without user interaction, prevent the removal of the MDM profile, and configure system-level settings like a global HTTP proxy. These enhanced capabilities are crucial for maintaining corporate compliance and security on devices owned by the organization.

A: Supervision is used to enforce organizational policies, which often limits user personalization rather than allowing it.

C: Supervision is a device management state; it does not directly modify network hardware or protocols to improve performance.

D: Separating personal and managed data is the primary function of User Enrollment for BYOD scenarios, not the core benefit of supervision.

1. Apple Platform Deployment (Fall 2023). "Supervision of Apple devices

" Page 31. The document states

"Supervision generally denotes that the device is owned by the organization

which provides additional control over its configuration and restrictions... A few examples of restrictions available for supervised devices only are: Disabling AirDrop

Preventing the user from erasing their device

[and] Preventing the user from changing their account settings."

2. Apple Developer Documentation. "MDM Protocol Reference

" Device Management section. Many payloads and commands

such as InstallApplication with the InstallAsManaged option for silent installation

and numerous keys within the Restrictions payload

explicitly list "Supervised: Yes" as a requirement

confirming that supervision enables these additional controls.

3. Stanford University IT. "Mobile Device Management (MDM) for iOS

" Section: "What is Supervision?". The documentation states

"Supervision allows for a higher level of device management... This includes the ability to apply additional restrictions

such as disabling iMessage or Game Center

and provides additional device configurations and features

such as silently installing apps or filtering web content."

The "Nonpersonalized, organization-owned" model refers to devices owned by an organization and configured for shared or single-purpose use, not assigned to a specific individual. This model, exemplified by features like Shared iPad or devices in kiosk mode, grants IT administrators the highest level of control. They can enforce strict policies to restrict which apps are installed, prevent users from storing personal data, and ensure the device remains in a standardized state for every user, which is essential for a shared environment.

A. BYOD, User Enrollment: This model is for personally owned devices. User Enrollment is designed to protect user privacy by separating work and personal data, giving IT limited control over the device.

B. BYOD, personally enabled: BYOD (Bring Your Own Device) inherently means the device is personally owned, not organization-owned. This model is unsuitable for a centrally managed, shared device scenario.

D. Personally enabled, organization-owned: This describes a device owned by the organization but assigned to a single user for both work and personal use. It is not a shared model and is designed to accommodate personal data.

1. Apple Platform Deployment Guide. (2024). Apple

Inc.

Section: "Choose a deployment model" -> "Organization-owned device deployment" -> "Shared deployment".

Content: This section explicitly details the "Shared iPad" and "Shared iPhone" models where organization-owned devices are shared among multiple users. It states

"Because the devices are organization-owned

you can configure them with the settings

apps

and services your users need

" which directly supports the concept of IT restricting apps and data in a non-personalized

shared context.

2. Stanford University IT. (2023). Mobile Device Management (MDM) at Stanford.

Section: "Device Ownership Models and Management Levels".

Content: The documentation distinguishes between personally-owned (BYOD) and university-owned devices. For university-owned devices

especially those in shared-use pools (e.g.

labs

loaner programs)

it describes a "fully managed" or "locked-down" state where administrators have complete control to restrict applications and data to comply with security and operational policies. This aligns with the "Nonpersonalized

organization-owned" model.

3. MIT Information Systems & Technology (IS&T). (2024). Mobile Device Management Service.

Section: "Device Enrollment Options".

Content: This resource outlines the differences in management capabilities based on device ownership. It clarifies that institutionally-owned devices enrolled through Apple Business Manager/School Manager can be fully supervised

allowing for comprehensive restrictions

which is a prerequisite for managing a shared

non-personalized device as described in the question.

On a personally owned device enrolled using Apple's User Enrollment framework, iOS creates a separate Apple File System (APFS) volume for all managed data. This volume is cryptographically separated from the user's personal data, using its own distinct set of encryption keys. A key component of this separated environment is a dedicated keychain for managed apps and accounts. This ensures that sensitive organizational credentials, certificates, and authentication tokens are stored securely and are inaccessible to personal apps, and vice-versa. Upon unenrollment, this entire volume, including the managed keychain, is securely destroyed.

B. Safari profiles: This is a user-facing feature within Safari for logically organizing browsing data (like history and cookies), not a fundamental, OS-level cryptographic separation mechanism enforced by MDM.

C. Safari bookmarks: While an MDM solution can push managed bookmarks, they are integrated into the Safari application. The core cryptographic separation applies to the entire managed data volume, not specifically to bookmarks.

D. Contacts: Although contacts from a managed account are stored on the separate managed volume, the keychain separation is a more fundamental security control that underpins the entire managed ecosystem on the device.

1. Apple Platform Security Guide (May 2024): Under the section "User Enrollment data separation

" the guide states

"For User Enrolled devices

iOS and iPadOS create a separate Apple File System (APFS) volume for managed data... This separation is secured by using a separate set of cryptographic keys for the data on the volume... This includes: ... A separate keychain for managed accounts." (Page 41).

2. Apple Developer Documentation

"User Enrollment": The documentation details the separation model: "User enrollment installs a separate volume on the device to store managed data... Managed apps and accounts have access to a separate keychain

which the system removes when the user unenrolls the device." (Section: "Separating Personal and Managed Data").

3. WWDC 2019

Session 303 "What's New in Apple Device Management": This session introduced User Enrollment and explained its core principles. It highlights the creation of a separate APFS volume and the cryptographic separation of work data

explicitly mentioning the separate keychain as a key privacy and security feature. (Timestamp: 10:15 - 11:30).