Zero Trust is a security strategy built on three guiding principles: verify explicitly, use least-privilege access, and assume breach.
Zero Trust is a security strategy, not a product, built on three principles: verify explicitly (authenticate and authorize using all available signals such as identity, location, and device health), use least-privilege access (limit permissions with just-in-time and just-enough access through tools like Microsoft Entra Privileged Identity Management), and assume breach (segment access, encrypt in transit, and use analytics to detect threats). A common exam confusion is treating Zero Trust as synonymous with Conditional Access; Conditional Access is one Microsoft Entra ID enforcement mechanism that implements Zero Trust, while Zero Trust is the broader strategy spanning Microsoft Defender XDR, Microsoft Purview, and Intune.
Authorization is the process of determining what an authenticated identity is allowed to do, typically enforced through roles, permissions, and group memberships.
Authorization determines what an already-verified identity is permitted to do within Microsoft 365 and its Copilot features. In Microsoft Entra ID (formerly Azure AD), authorization is enforced primarily through role-based access control (RBAC): admin roles such as Global Administrator, Teams Administrator, or AI Administrator each carry a bounded set of permissions rather than blanket access. Conditional Access policies add another layer, restricting actions based on device compliance, location, or risk. Authorization is always a separate step that follows authentication. In Copilot and agent scenarios, least privilege means granting only the minimum Microsoft Graph permissions a task requires.
Authentication is the process of proving a user's identity, using methods such as passwords, the Microsoft Authenticator app, FIDO2 security keys, Windows Hello, and passkeys.
Microsoft Entra ID supports a range of authentication methods — passwords, the Microsoft Authenticator app, FIDO2 security keys, Windows Hello for Business, certificate-based authentication, and passkeys — that administrators control through the Authentication methods policy in the Entra admin center, enabling or disabling each method per user group. A key exam distinction is that Microsoft is consolidating method management into this policy and retiring the legacy per-user MFA settings. Phishing-resistant methods such as FIDO2, passkeys, and Windows Hello for Business resist adversary-in-the-middle attacks, making them preferred for privileged accounts and Conditional Access requirements.
MFA requires a user to provide two or more verification factors — something they know, have, or are — before access is granted.
Multifactor authentication requires verifying identity with at least two independent factors — typically a password plus a code from the Microsoft Authenticator app, an SMS, or a FIDO2 hardware key. In Microsoft 365, MFA is enforced through Microsoft Entra ID (formerly Azure Active Directory), so a single policy can protect the tenant. The key exam distinction is MFA versus passwordless: passwordless replaces the password entirely (Windows Hello for Business or a FIDO2 key), while traditional MFA keeps the password as one factor. Security Defaults enable per-user MFA on newer tenants that have no Conditional Access policies configured, so know when each applies.
SSO lets a user authenticate once with Microsoft Entra ID and then access multiple connected applications without signing in again.
Microsoft Entra ID acts as the identity provider for SSO. After one sign-in, Entra ID issues OAuth 2.0 and OpenID Connect tokens that connected apps accept without a second prompt, covering Microsoft 365 apps like Teams and SharePoint plus third-party SaaS apps in the enterprise applications gallery. A key exam point: password hash synchronization brings on-premises Active Directory credentials into Entra ID but does not by itself enable silent SSO; Entra seamless SSO must be configured separately, using Kerberos on domain-joined devices. Copilot and agent scenarios rely on this so delegated, signed-in-user context uses valid tokens.
Conditional Access is a Microsoft Entra ID feature that enforces access policies using if-then rules combining signals such as user, device, location, and risk with controls like requiring MFA.
Conditional Access is a Microsoft Entra ID feature that evaluates real-time signals — user identity, device compliance state, location, and sign-in risk — and applies if-then policy rules to access requests before granting entry to Microsoft 365 apps, including Copilot experiences. A matching policy can grant access, require multifactor authentication, demand a compliant or Entra hybrid-joined device, or block entirely. A common exam trap is treating MFA as a competing feature: MFA is one grant control it can enforce. Policies are configured in the Microsoft Entra admin center and fire at the authentication layer before any app loads.
Risky sign-ins are authentication attempts that Microsoft Entra ID Protection flags as suspicious, such as sign-ins from anonymous IPs, atypical travel, or leaked credentials.
Risky sign-ins are authentication events that Microsoft Entra ID Protection evaluates and assigns a risk level — low, medium, or high — based on signals such as anonymous or malicious IP addresses, atypical travel between distant locations, unfamiliar sign-in properties, or leaked credentials. The risk is surfaced in the Entra admin center and can feed Conditional Access policies. The key exam distinction is sign-in risk versus user risk: sign-in risk reflects a single suspicious authentication, while user risk indicates the account itself may be compromised. Conditional Access can require MFA or block access in real time, whereas remediating user risk typically requires a password reset.
Identity Secure Score is a percentage in Microsoft Entra ID that shows how closely a tenant's identity configuration aligns with Microsoft's security best practices.
Identity Secure Score is a numeric percentage in Microsoft Entra ID that measures how closely a tenant’s identity configuration aligns with Microsoft’s recommended security best practices. It evaluates controls like requiring multi-factor authentication, eliminating legacy authentication, and enabling Conditional Access, then surfaces ranked improvement actions with estimated score impact. The key exam distinction is that it is a subset of the broader Microsoft Secure Score, which also covers device and app categories. Expect questions contrasting where Identity Secure Score appears (the Microsoft Entra admin center) with where the combined Secure Score lives (the Microsoft Defender portal).
Audit logs record user and admin activity across Microsoft 365 and Microsoft Entra, providing a searchable history for security investigations and compliance.
Audit logs capture timestamped records of user and administrator actions across Microsoft 365, surfaced through two distinct stores. The Microsoft Purview audit log (in the Purview compliance portal) covers workload activity such as SharePoint file access, Exchange mail actions, and Copilot interaction events. The Microsoft Entra audit log separately records identity changes — role assignments, group modifications, and consent grants — while Entra sign-in logs track authentication. A common exam trap is treating these as one unified log; they are separate systems with separate retention defaults, and Purview Audit (Premium), available with E5, extends retention well beyond the standard defaults.
PIM is a Microsoft Entra ID Governance feature that provides time-based and approval-based activation of privileged roles to limit standing administrative access.
Privileged Identity Management is a Microsoft Entra ID Governance feature that eliminates permanently assigned (“standing”) access to sensitive roles such as Global Administrator or SharePoint Administrator. Instead of holding a role continuously, an eligible user must consciously activate it, typically supplying a justification, completing multifactor authentication, or waiting for an approver’s sign-off. The role then expires automatically after a configurable time-bound window. A critical exam distinction is eligible versus active assignments: an active assignment grants the role immediately with no activation step, while eligible assignments are the core just-in-time PIM control. This also matters for Copilot scenarios, since agents and connectors stay bound by the same Entra ID role boundaries PIM governs.
Microsoft Defender XDR is a unified enterprise defense suite that coordinates detection, investigation, and response across endpoints, identities, email, and apps from the Microsoft Defender portal.
Microsoft Defender XDR (extended detection and response) unifies signals from Microsoft Defender for Endpoint, Defender for Identity, Defender for Office 365, and Defender for Cloud Apps into a single incident view within the Microsoft Defender portal. By correlating alerts across these pillars automatically, it reduces the time a security team spends pivoting between separate consoles to reconstruct an attack chain. A common exam confusion is treating Defender XDR as endpoint-only: Defender for Endpoint covers devices, while XDR is the cross-workload correlation layer above it. Automatic attack disruption can isolate a compromised device or suspend a risky account mid-attack.
An app registration creates the global application object (the app's identity blueprint) in its home tenant, while an enterprise application is the local instance (service principal) in a specific tenant where admins manage that app's access, consent, and SSO.
In Microsoft Entra ID, an app registration creates the application object — the global identity blueprint stored in the app’s home tenant, holding its client ID, credentials, and permission scopes. When that app is added to a tenant, Entra ID provisions a corresponding enterprise application, the local service principal admins use to manage user assignment, Conditional Access, consent, and single sign-on. The exam-critical point: you never assign users to the registration itself. The registration owns the app’s definition; the enterprise application owns each tenant’s relationship with it.