Apple Deployment & Mgmt common mistakes
Apple Deployment & Mgmt · Understand the traps and how to avoid them.
Treating Automated Device Enrollment (ADE) as if it wipes and re-enrolls a device when a user signs out of iCloud or erases the device, rather than recognizing that supervision and MDM enrollment persist through those user actions.
Candidates conflate ADE with manual profile installation, where removing the MDM profile or erasing the device drops management. Because manual enrollment behaves that way, they overgeneralize it to ADE.
What to do instead
Learn the ADE lifecycle explicitly: devices are assigned in Apple Business Manager, supervision and MDM enrollment are established at setup, and they survive user sign-out and local erase. Only removing the device from ABM assignment or explicitly unenrolling (where permitted) removes management.
Assuming a manually installed configuration profile on macOS can be removed by the user in System Settings the same way an MDM-installed profile can, and answering questions as if manual and MDM profiles have identical removal rules.
The UI presents both profile types in the same Profiles pane, so candidates assume identical behavior without checking the enrollment source.
What to do instead
Memorize the distinction: manually installed profiles are user-removable; MDM-installed profiles on supervised/enrolled devices are not user-removable, and on macOS the MDM payload can be made non-removable. Always ask 'who installed it and is the device supervised?' before answering.
Confusing Apple Business Manager roles and scope, e.g., assuming an ABM administrator can also manage Apple School Manager content or that a 'Device Enrollment Manager' can assign devices in ABM.
The role names sound administrative and overlap in everyday language, and candidates study one console in depth and assume the others mirror it.
What to do instead
Build a role table per console (ABM/ASM): Administrator, Device Enrollment Manager, Content Manager, Manager, Staff. Note that DEM is an MDM-side role for enrolling devices, not an ABM assignment role, and that ABM and ASM are separate instances with separate accounts.
Answering MDM command questions by assuming commands are guaranteed to execute immediately, rather than recognizing that commands are queued and depend on the device checking in via APNs.
Candidates think of MDM as a direct connection to the device and overlook the push-notification-then-check-in model.
What to do instead
Internalize the flow: MDM server sends an APNs push, the device wakes and contacts the MDM server, then pulls queued commands. Troubleshooting starts with 'is APNs reachable and is the device checking in?' before blaming the MDM vendor.
Treating declarative device management (DDM) as a drop-in replacement for all MDM commands and profiles, and answering as if configurations are still pushed by the server in every case.
Study material covers classic MDM profiles heavily, and DDM's inverted model (device declares status, server sends declarations) is easy to skim past.
What to do instead
Learn the DDM model: declarations (configurations, assets, activations) are evaluated on-device, and the device reports status back. Know which capabilities are declaration-based versus still command-based, and that DDM requires a minimum OS version.
Assuming any Mac can be enrolled in MDM and supervised without Apple Business Manager or Apple Configurator, and answering supervision questions without naming the required tool.
Supervision and enrollment are often discussed together, so candidates blur the line between 'enrolled' and 'supervised'.
What to do instead
Anchor supervision to its two sources only: ADE via ABM/ASM, or Apple Configurator for Mac. Enrollment alone (manual profile install) does not confer supervision, and supervision is what unlocks the restricted settings and non-removable MDM.
Recommending FileVault enablement without accounting for the recovery key escrow and institutional key workflow, and answering as if FileVault is simply 'turn on disk encryption'.
FileVault is familiar from consumer use, so candidates skip the managed-specific behaviors around escrow, rotation, and the secure token requirement.
What to do instead
Study the managed FileVault flow: escrow to MDM, personal recovery key vs institutional key, key rotation, and the secure token/bootstrap token requirement for enabling FileVault on Apple silicon and T2 Macs. Link it to the account that holds the secure token.
Treating Activation Lock and Find My as the same thing and assuming disabling Find My is sufficient to release a device, rather than addressing Activation Lock via ABM or the bypass code.
Both features are tied to the user's Apple Account and both appear in device settings, so the underlying ownership model is easy to miss.
What to do instead
Distinguish them: Find My is a user service; Activation Lock is an ownership lock tied to the Apple Account or, for supervised devices, to ABM. For managed devices, use ABM to clear Activation Lock or the device's bypass code. For user devices, the user must sign out or remove the device from their account.
Diagnosing a Mac that won't boot or won't install updates by jumping straight to reimaging, instead of working through startup security, recoveryOS, and the startup disk selection first.
Candidates default to 'erase and reinstall' because it is a familiar fix, skipping the ordered diagnostic path the exam expects.
What to do instead
Follow an ordered path: verify startup disk in Startup Disk preferences, check Startup Security Utility settings on Apple silicon/T2, boot to recoveryOS for First Aid and reinstall, and confirm the firmware password or MDM restrictions before erasing.
Assuming an iPhone or iPad that fails to install a configuration profile or reach the MDM server has a device fault, rather than checking certificate trust, APNs connectivity, and the enrollment state first.
The visible symptom is on the device, so candidates localize the fault to hardware or iOS instead of the enrollment and trust chain.
What to do instead
Use a layered checklist: is the device supervised/enrolled, is the MDM push certificate valid and not expired, is APNs reachable on the network, is the profile signed and trusted, and does the device check in? Only after those pass should you consider erase or restore.