On a managed Mac fleet, what is a configuration profile, and what can an MDM enforce through one that a shell script running as root on the same machine cannot?

## What a profile actually is A configuration profile is a property list, conventionally with a `.mobileconfig` extension, containing an ordered array of **payloads**. Each payload has a type identifier (`PayloadType`), a unique identifier, and the settings it carries. The document as a whole has an identifier and a UUID, and it is normally **signed** so macOS can display the issuing organisation and refuse a tampered copy. Payloads span most of what "managing a Mac" means: network configuration (Wi-Fi, VPN, proxies), trusted certificates, restrictions, login-window behaviour, FileVault settings including escrow of the recovery key, software-update policy, and — the general-purpose escape hatch — **managed preferences**, which set arbitrary keys in an arbitrary preference domain. ## Managed preferences beat local writes When a profile carries a managed-preference payload, macOS materialises those values under `/Library/Managed Preferences/`, and the preferences search order consults them ahead of the user and machine domains. The practical consequence is the one that separates a scripted Mac from a managed one: a user can run `defaults write` for the same key, get no error, and change nothing. Configuration set by script is advisory and drifts the moment somebody changes it back; configuration set by profile is enforced continuously and is removed only when the profile is removed. This is why the mature answer to "how do we make sure every laptop has setting X" is a profile, not a script in the login flow. ## The delivery change that catches people out Historically an admin could install a profile from a script. **Since macOS 11, command-line installation of configuration profiles was removed.** Today there are two routes: 1. **Manual** — the user opens the `.mobileconfig`, and macOS routes it to System Settings where it must be explicitly reviewed and approved. Nothing installs silently. 2. **MDM** — the device is enrolled with a management server, which pushes profiles over the MDM protocol without user interaction. So an automation plan that assumes "we will just drop the profile with a script" is out of date, and saying so is a strong signal in an interview. The `profiles` command still exists for inspection and enrollment operations: ```bash profiles list # installed profiles (root for device profiles) profiles show -type enrollment # enrollment configuration profiles status -type enrollment # enrolled? user-approved? DEP? profiles renew -type enrollment # re-request the enrollment profile ``` ## What only a supervised, MDM-managed Mac can do A second tier of payloads is not merely inconvenient to install by hand — it is **ignored** unless the Mac is supervised (typically through Automated Device Enrollment) and enrolled in MDM. The important members: - **Privacy preferences policy control (PPPC)** — pre-approving an application's access to protected resources such as full disk access or the ability to control other applications. This is the only supported way to grant those approvals without a human clicking a consent dialog on every machine. - **Kernel and system extension allowlists** — permitting a specific vendor's extension to load without the user approving it in settings. - **Enforced software-update policy and deferral** — restricting or delaying updates through the restrictions domain `com.apple.applicationaccess`, up to a documented maximum deferral window. - **FileVault recovery-key escrow** — capturing the key centrally, which is what makes full-disk encryption operable at fleet scale rather than a support disaster. The common thread is that each of these is a security decision macOS will otherwise only accept from a human sitting at the machine. Supervision is the assertion that the organisation owns the device, and it is what converts "the user must consent" into "the owner has decided". ## Where profiles stop Profiles configure; they do not run code. Installing software, running remediation, collecting inventory and executing one-off commands are the *other* half of fleet management, handled by the MDM's own commands and by an agent. A good answer draws that line: policy in profiles, actions in the management agent or MDM commands, and never a login script trying to do the policy's job. Removal matters too. A profile installed by MDM is generally removable only by the MDM (locked profiles cannot be removed by the user), and removing a profile reverts its managed preferences — the underlying user values reappear rather than the managed ones persisting. That reversibility is a feature: it makes policy auditable and undoable in a way that scattered `defaults write` calls never are. ## What the interviewer wants Name the artifact (signed plist of typed payloads), state the enforcement property (managed preferences outrank local writes), get the delivery constraint right (no command-line installation since macOS 11 — user approval or MDM), and give at least one capability that requires supervision. That combination shows you have managed real Macs rather than read a payload reference.