Intune interviews test your ability to manage thousands of devices at scale. These questions come from real hiring panels for Endpoint Engineer and M365 Administrator roles.
Intune (Microsoft Endpoint Manager) interviews are heavily scenario-based. Interviewers don't care if you know what Windows Autopilot is — they care whether you've actually deployed it at scale and know what breaks. Expect questions about Hybrid Azure AD Join failures, compliance policy conflicts, and co-management scenarios.
Azure AD Join registers a device only in Azure AD. No on-premises AD required. Users sign in with their Azure AD credentials. Best for new devices in cloud-first organisations, or BYOD with MAM. Hybrid Azure AD Join registers in both on-premises AD AND Azure AD. The device must be domain-joined first, and Azure AD Connect must be configured to sync device objects. Required when: you need GPO for on-prem resources, SCCM/MECM co-management, or Kerberos-based authentication for on-prem apps. Key interview point: Hybrid AAD Join requires the device to have line-of-sight to a domain controller during the registration process — remote devices need VPN or DRS configured with a service connection point.
Autopilot is a cloud-native zero-touch deployment service. Instead of imaging devices, IT pre-registers device hardware IDs in the Autopilot portal. When a user powers on a new (or wiped) device, it contacts Microsoft's Autopilot service, downloads the organisation's Autopilot profile, and automatically enrols in Intune. The user experience is: enter Azure AD credentials → device configures itself. Modes: User-driven (most common — user signs in and device joins Azure AD or Hybrid Azure AD during OOBE); Self-deploying (no user interaction — for kiosks and shared devices, requires TPM 2.0); Pre-provisioning / White Glove (IT or partner pre-configures the device before shipping to user — apps and policies applied before user touches it); Existing Devices (converts SCCM-managed machines to co-management via Autopilot).
Work through the assignment chain: (1) Check the Autopilot profile assigned to the device group — is the device in the correct dynamic or assigned group? Use Intune → Devices → Windows → the specific device → check "Group memberships". (2) Check app assignments — is the app assigned to the same group, as "Required"? (3) Check the Device install status for the app under Apps → the app → Device install status. (4) On the device: Event Viewer → Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider — look for enrollment and policy errors. (5) Run mdmdiagnosticstool.exe -area Autopilot;DeviceEnrollment;DeviceProvisioning -cab c:mdmlogs.cab for full diagnostic logs.
They serve different purposes and don't directly conflict. Compliance policies evaluate device state and mark devices as compliant or non-compliant — they don't push settings. Configuration profiles actively push settings to devices. A device can be non-compliant (e.g., BitLocker not enabled) while still receiving configuration profiles (e.g., Wi-Fi settings). Where conflict occurs: if multiple configuration profiles push contradictory settings (e.g., two profiles both configure Windows Update settings differently), the last one wins — but this is unpredictable. Best practice: use a single profile per setting area, use scope tags to target devices cleanly, and use the Intune "Device configuration — Profile report" to check what's applied.
Create an Endpoint Security → Disk Encryption → BitLocker policy. Key settings: require BitLocker for OS drives (AES-256), enable TPM startup, configure recovery key escrow to Azure AD. For rollout strategy: assign to a pilot group of ~50 devices first. Monitor via Intune's encryption report (Devices → Monitor → Encryption report). For devices that already have BitLocker enabled, Intune will take management of existing keys. The most common pitfall: devices with BIOS (not UEFI) can't use TPM-based BitLocker — check your hardware baseline first and exclude BIOS devices from the policy.
Co-management lets SCCM and Intune share management authority over Windows 10/11 devices simultaneously. Enable it in SCCM: Administration → Cloud Services → Co-management → Enable. Configure workloads — you can move specific workloads from SCCM to Intune incrementally: Compliance Policies, Resource Access (Wi-Fi, VPN, cert profiles), Device Configuration, Endpoint Protection, Windows Update policies, Apps (modern apps to Intune, Win32/legacy to SCCM). The recommended approach: move Compliance Policies first (least risky), then Windows Update policies, then progressively move other workloads as you validate. Keep app deployment in SCCM until Intune app deployment is fully tested — app delivery failure is the most user-visible disruption.
Practice scenario questions with InterviUni's Intune/Endpoint mock interview — real hiring-manager questions, scored feedback on every answer.
Practice AI mock interviews, check your ATS score, or start a cert course — free.