Scenario practice questions

An employee uses their Microsoft Entra ID to sign in to a third-party SaaS application.

Why it fails: This describes a standard Single Sign-On (SSO) implementation for internal employees, leveraging Microsoft Entra ID as the identity provider for third-party SaaS applications. While it uses Microsoft Entra ID for authentication, it does not involve inviting external users or managing guest accounts for cross-organizational collaboration. Instead, it streamlines access for an organization's own workforce to applications outside its direct control.

Two internal departments share resources within the same tenant.

Why it fails: Sharing resources between internal departments within the same Microsoft Entra tenant is a fundamental aspect of internal access management, not B2B collaboration. All users involved are employees of the same organization, with their identities already managed within the single Microsoft Entra directory. This process relies on internal group memberships, permissions, and access policies, without the need for external identity federation or guest accounts.

Customers use their Facebook accounts to sign in to a company's web application.

Why it fails: This scenario describes Microsoft Entra B2C (Business-to-Consumer), which is designed for managing customer identities and access to consumer-facing applications. B2C allows customers to sign in using social identity providers like Facebook or by creating local accounts. This differs fundamentally from B2B, which focuses on inviting users from other organizations' directories for business collaboration, rather than managing individual consumer accounts.

The sensitive info type 'EU_Deutschland_SocialSecurityNumber' is not defined in the tenant.

Why it fails: The sensitive information type 'EU_Deutschland_SocialSecurityNumber' is a standard, built-in sensitive information type provided by Microsoft Purview. These built-in types are universally available across all tenants and and do not require explicit definition or configuration by an administrator to be recognized. Therefore, the premise that it is not defined in the tenant is incorrect, as it's part of the default Purview classification capabilities.

The encryption setting prevents auto-labeling on emails.

Why it fails: Encryption, when configured as part of a sensitivity label, is an *effect* of applying that label, not a prerequisite or a blocker for auto-labeling. Auto-labeling policies are designed to identify sensitive content and then apply the appropriate label, which may or may not include encryption settings. Therefore, the presence or absence of an encryption setting does not inherently prevent an auto-labeling policy from functioning and applying a label to emails.

The label is not published to users.

Why it fails: While publishing a sensitivity label to users is necessary for manual application of the label by end-users in their applications, it is not strictly required for server-side auto-labeling policies to function. Auto-labeling policies operate at the service level (e.g., Exchange Online, SharePoint Online) to automatically detect and apply labels based on defined conditions, independent of whether the label is visible or available for manual selection by individual users.

OAuth 2.0

Why it fails: OAuth 2.0 is primarily an authorization framework that enables a third-party application to obtain limited access to an HTTP service on behalf of a resource owner. It focuses on delegated access to resources rather than authenticating a user directly or federating identity between distinct identity providers. While often used in conjunction with OpenID Connect for authentication, OAuth 2.0 itself does not provide identity federation capabilities for single sign-on between organizations.

SCIM

Why it fails: The System for Cross-domain Identity Management (SCIM) is an open standard designed for automating the exchange of user identity information between identity domains or cloud applications. Its primary purpose is to provision, deprovision, and update user accounts and group memberships across different systems efficiently. SCIM is not intended for authenticating users or establishing trust relationships for single sign-on between disparate identity providers, which is the core function of federation.

OpenID Connect

Why it fails: OpenID Connect (OIDC) is an authentication layer built on top of the OAuth 2.0 framework, allowing clients to verify the identity of the end-user based on the authentication performed by an Authorization Server. It provides a standardized way for applications to obtain basic profile information about the authenticated user through ID tokens. While OIDC facilitates authentication, its primary use case involves integrating applications with an identity provider, rather than enabling direct identity federation between two distinct organizational identity providers for cross-domain single sign-on.

Self-Service Password Reset

Why it fails: Self-Service Password Reset (SSPR) allows users to reset their forgotten passwords without requiring administrator intervention. While essential for regaining access due to forgotten credentials, SSPR does not provide feedback to a user regarding why their access to a cloud application was blocked by an active policy, nor does it offer guidance on how to remediate a policy-based access restriction. It addresses credential issues, not policy compliance failures.

Multifactor Authentication registration

Why it fails: Multifactor Authentication (MFA) registration is the process where users set up and enroll additional verification methods, such as a phone or authenticator app, to strengthen their sign-in security. Although MFA is frequently a requirement enforced by access policies, the registration process itself does not provide specific, user-facing feedback about *why* a cloud app access attempt was blocked by a policy, nor does it offer remediation steps beyond the act of enabling MFA if that was the sole missing requirement.

Identity Protection risk policies

Why it fails: Microsoft Entra ID Protection risk policies are designed to detect potential vulnerabilities affecting an organization's identities, such as compromised credentials or suspicious sign-in behaviors. These policies can automatically block access or require MFA based on detected risk levels. However, their primary function is risk detection and automated response, not to provide explicit, user-friendly feedback detailing *which* specific policy condition was violated or how to directly remediate the policy requirement that led to the access block.

Require device to be marked as compliant

Why it fails: Incorrect. While this control can enforce device compliance (e.g., Intune), the scenario does not mention a need for device compliance; it only specifies unmanaged device status (which is a condition, not a grant). The requirement is for MFA from unmanaged devices, which is handled by the 'Require MFA' grant.

Require approved client app

Why it fails: This grant control specifically restricts access to only those client applications that are explicitly designated as "approved" by the organization, such as Microsoft Outlook or Teams mobile apps with Intune App Protection Policies. It does not address device compliance, sign-in risk, or the need for stronger authentication. Therefore, if the requirement is to enforce MFA from unmanaged devices or block high-risk sign-ins, this control is irrelevant as it focuses solely on the client application's identity and management status.

Anomaly detection rule

Why it fails: Anomaly detection rules in Microsoft Sentinel are primarily driven by machine learning algorithms that establish a baseline of normal behavior and then flag deviations from that baseline. These rules are designed to identify unusual activities or patterns that might indicate a threat, rather than executing custom, user-defined correlation logic across specific events over a fixed 24-hour period. They are not suitable for scenarios requiring explicit KQL queries to join and analyze events based on custom criteria.

Fusion rule

Why it fails: Fusion rules in Microsoft Sentinel leverage advanced artificial intelligence and machine learning to automatically correlate multiple low-fidelity alerts across different products into high-fidelity, actionable incidents. While powerful for detecting multi-stage attacks, Fusion is a pre-built, proprietary correlation engine focused on alerts, not raw events. It does not allow for custom KQL logic to define specific event correlations over a user-defined 24-hour period.

Near-real-time (NRT) rule

Why it fails: Near-real-time (NRT) rules are designed for rapid threat detection, running KQL queries as frequently as every minute to identify immediate threats. While they offer speed, their primary purpose is for short-duration, high-frequency checks, not for correlating events that span an entire 24-hour period. An NRT rule's 1-minute interval and typical lookback window are optimized for immediate alerts, making it inefficient and unsuitable for comprehensive daily correlation tasks requiring a broader time scope.

Conditional Access

Why it fails: Conditional Access policies enforce specific controls based on various conditions, such as user location, device compliance, sign-in risk, or application, to determine whether a user can access a resource. These policies are applied *after* an application has been granted consent and a user attempts to sign in, governing *how* and *when* access is permitted. Conditional Access does not, however, manage the initial process of requesting or granting consent for an application's required permissions.

Identity Protection

Why it fails: Microsoft Entra ID Protection is a security module focused on detecting, investigating, and remediating identity-based risks, such as suspicious sign-ins, leaked credentials, or anomalous user behavior. It leverages machine learning to identify potential threats to user identities and can trigger automated responses like multi-factor authentication enforcement or password resets. This service is entirely distinct from the process of managing user or admin consent for application permissions, as its scope is risk detection, not application authorization workflows.

Privileged Identity Management (PIM)

Why it fails: Privileged Identity Management (PIM) is designed to manage, control, and monitor access to important resources within Microsoft Entra ID, Azure, and other Microsoft services by providing just-in-time (JIT) and just-enough-administration (JEA) access to privileged roles. While crucial for securing administrative functions, PIM does not facilitate or manage the process of users requesting consent for application permissions. Its focus is on elevating user roles temporarily, not on granting organizational consent for applications.

Conditional Access policies

Why it fails: Conditional Access policies are an enforcement engine that uses signals from various sources, including Microsoft Entra ID Protection, to make access decisions. While it can block access or require additional authentication based on a detected risk, Conditional Access itself does not possess the inherent capability to detect compromised credentials. It relies on upstream services like Identity Protection to provide the risk assessment before applying its access controls.

Privileged Identity Management (PIM)

Why it fails: Privileged Identity Management (PIM) focuses on managing, controlling, and monitoring access to important resources within Microsoft Entra ID, Azure, and other Microsoft services. Its primary function is to provide just-in-time and just-enough access for privileged roles, reducing the attack surface associated with standing administrative permissions. PIM is not designed to detect or prevent the compromise of standard user credentials, but rather to secure the use of high-privilege accounts.

Self-Service Password Reset (SSPR)

Why it fails: Self-Service Password Reset (SSPR) empowers users to reset their own forgotten or expired passwords without administrator intervention. While it improves user experience and reduces helpdesk calls, SSPR does not include any mechanisms for proactively detecting or blocking compromised credentials. It is a reactive tool for password management, not a security service for identifying and mitigating identity-based threats like credential compromise.

Microsoft Purview eDiscovery (Standard)

Why it fails: Microsoft Purview eDiscovery (Standard) offers foundational search and export capabilities for content across Microsoft 365, suitable for basic investigations or regulatory requests. However, it lacks the advanced features essential for comprehensive legal proceedings, such as the ability to identify and manage specific custodians, apply targeted legal holds, or leverage sophisticated analytics and machine learning tools for efficient document review and culling. Consequently, it is insufficient for the rigorous demands of a full-scale lawsuit requiring extensive data gathering and analysis.

Microsoft Purview Audit (Premium)

Why it fails: Microsoft Purview Audit (Premium) is primarily designed to provide detailed logging and forensic investigation capabilities for user and administrator activities within Microsoft 365 services. While invaluable for understanding security incidents, compliance breaches, or user behavior, it does not offer any functionality for placing legal holds on data to prevent modification or deletion, nor does it facilitate the collection, processing, or review of electronically stored information (ESI) for legal discovery purposes. Its focus is on activity monitoring, not data preservation or collection for litigation.

Microsoft Purview Data Lifecycle Management

Why it fails: Microsoft Purview Data Lifecycle Management (DLM) is centered on managing the retention and deletion of data throughout its lifecycle using retention policies and labels. While DLM can prevent data from being prematurely deleted and ensure compliance with retention requirements, it is not designed to implement specific, targeted legal holds for litigation. It lacks the ability to identify custodians, apply holds based on legal case requirements, or provide the advanced collection, processing, and review tools necessary for a comprehensive eDiscovery workflow.

Confidentiality

Why it fails: Confidentiality protects information from unauthorized disclosure, ensuring that only authorized individuals can access or read sensitive data. While the email being encrypted inherently provides confidentiality by preventing unauthorized parties from reading its content, the specific action described is the user *verifying* that the message content has not been *altered*. This verification process directly addresses integrity, even though confidentiality is also present due to encryption.

Availability

Why it fails: Availability ensures that authorized users can access information and systems when needed, without undue delay or interruption. The scenario describes a user successfully receiving and interacting with an email, indicating that the email service and the message itself were available. The act of verifying the message's content for alteration does not relate to the accessibility or uptime of the system or data, but rather to its trustworthiness.

Non-repudiation

Why it fails: Non-repudiation provides irrefutable proof of an action, preventing a sender from denying they sent a message or a recipient from denying they received it. While digital signatures can provide non-repudiation by linking a message to a specific sender, the scenario's focus is on verifying the *content's state* (unchanged), not on proving the sender's identity or preventing their denial of sending the email. Therefore, verifying content alteration is distinct from non-repudiation.

Authentication

Why it fails: Authentication is the initial security step where a user or system proves their asserted identity, typically through credentials like usernames and passwords, biometrics, or certificates. Its sole purpose is to verify "who you are," confirming the legitimacy of the entity attempting to gain access. While essential for entry, authentication itself does not dictate what specific resources or actions that verified identity is allowed to perform once inside the system.

Accounting

Why it fails: Accounting, often referred to as auditing, involves systematically tracking and logging all user activities, resource consumption, and system events within a network or application. Its primary function is to create a comprehensive audit trail, enabling security administrators to review "what happened, when, and by whom." This data is crucial for forensic analysis, compliance reporting, and identifying potential security breaches, but it does not directly govern whether access is granted or denied in real-time.

Non-repudiation

Why it fails: Non-repudiation is a security service designed to provide irrefutable proof that a specific action or event occurred and originated from a particular source. It prevents an entity from successfully denying responsibility for a past action, often achieved through digital signatures or cryptographic hashing that binds an action to an identity. This concept is distinct from access control, as it focuses on accountability and trustworthiness of past actions rather than real-time access decisions.

A retention label to retain credit card data

Why it fails: A retention label is designed to manage the lifecycle of data, ensuring it is kept for a specific period or deleted after a set duration to meet regulatory or organizational requirements. While crucial for data governance, retention labels do not actively scan content for sensitive information types (SITs) like credit card numbers to prevent sharing or exfiltration. Their function is data retention and deletion, not real-time data loss prevention.

An audit policy to log credit card sharing

Why it fails: An audit policy is designed to record user and administrator activities within Microsoft 365 services, creating a comprehensive log of events for compliance, security investigations, and forensic analysis. While an audit policy could log instances of credit card data being shared, its function is purely reactive—it documents what happened after the fact. It does not possess the capability to proactively detect sensitive content or block the sharing action in real-time.

A sensitivity label that marks credit card data

Why it fails: Sensitivity labels in Microsoft Purview are used to classify and apply persistent protection to sensitive content by adding visual markings (like headers, footers, or watermarks) and encryption. While a sensitivity label can indicate that data contains credit card information, the label's primary function is classification and persistent protection, not the real-time blocking of sharing actions. Blocking sharing is typically an enforcement action taken by a DLP policy, often in conjunction with or triggered by a sensitivity label, but not solely by the label itself.

Windows Hello for Business

Why it fails: Windows Hello for Business is a robust credential management system designed specifically for Windows 10/11 devices, enabling strong user authentication through biometrics (face or fingerprint) or PIN. It provisions a user-specific, device-bound key or certificate for sign-in, eliminating passwords on the local device. However, it is an operating system feature integrated into Windows and does not extend its biometric capabilities directly to mobile operating systems like iOS or Android for cloud service authentication. Therefore, it cannot fulfill a requirement for mobile biometric sign-in.

SMS-based sign-in

Why it fails: SMS-based sign-in allows users to authenticate by entering their registered phone number and then receiving a one-time passcode (OTP) via text message, which they then input into the sign-in prompt. While it offers a convenient method for multi-factor authentication or even primary sign-in, this approach relies solely on possession of the registered mobile device and knowledge of the OTP. It does not incorporate or leverage any biometric verification methods such as fingerprint or facial recognition from the mobile device itself.

FIDO2 security keys

Why it fails: FIDO2 security keys are physical hardware devices that provide strong, phishing-resistant authentication by generating cryptographic credentials. These keys typically connect via USB, NFC, or Bluetooth to a device and often incorporate their own biometric sensors (e.g., fingerprint readers) or PIN pads for user verification on the key itself. While highly secure, they are external hardware tokens and do not utilize the built-in biometric capabilities of a user's mobile phone for authentication to cloud services.

A

Why it fails: Microsoft Entra Conditional Access enforces policies based on real-time conditions like user location, device compliance, or sign-in risk during an authentication attempt. Its primary function is to grant or block access, or require additional authentication, at the point of access. It does not provide a mechanism for scheduled, periodic reviews of existing group memberships or application assignments, nor does it automate the removal of access based on such reviews.

B

Why it fails: Microsoft Entra Identity Protection is a security feature focused on detecting, investigating, and remediating identity-based risks, such as compromised credentials or anomalous sign-in behaviors. It uses machine learning to identify potential threats to user identities. While crucial for security, it does not offer functionality for managing periodic access reviews of group memberships or application assignments, nor does it automate the removal of access based on a review process.

D

Why it fails: Microsoft Entra Privileged Identity Management (PIM) focuses on managing, controlling, and monitoring access to important organizational resources, primarily by providing just-in-time (JIT) and just-enough-access (JEA) for privileged roles and resources. While PIM includes access reviews for *privileged* role assignments and PIM-enabled groups, its scope is specifically privileged access, not general, periodic reviews of all group memberships or application assignments for non-privileged users.

Microsoft Entra Privileged Identity Management (PIM)

Why it fails: Microsoft Entra Privileged Identity Management (PIM) enables organizations to manage, control, and monitor access to important resources within Microsoft Entra ID and Azure. It provides just-in-time access and approval workflows for *roles*, such as Microsoft Entra ID administrative roles or Azure resource roles (e.g., Virtual Machine Contributor). While it offers JIT principles, it does not directly manage or control access to specific network ports (like RDP or SSH) on individual virtual machines themselves, which is the core requirement here.

Microsoft Defender for Identity

Why it fails: Microsoft Defender for Identity is a cloud-based security solution focused on detecting advanced threats, compromised identities, and malicious insider actions targeting on-premises Active Directory environments. It monitors user behavior and detects anomalies related to identity-based attacks, such as pass-the-hash or golden ticket. However, it does not provide functionality for managing or granting just-in-time access to administrative ports (like RDP or SSH) on virtual machines, making it unsuitable for this specific security control.

Microsoft Defender for Cloud Apps

Why it fails: Microsoft Defender for Cloud Apps functions as a Cloud Access Security Broker (CASB), offering comprehensive visibility, control, and threat protection across cloud applications and services. It helps identify shadow IT, enforce data loss prevention policies, and detect anomalous behavior within SaaS applications. However, its scope is entirely focused on cloud application security and data governance, and it does not provide any mechanism for managing just-in-time access to administrative ports on virtual machines.

Alert trigger

Why it fails: An alert trigger fires when a Microsoft Sentinel alert is created, but the requirement is to block the IP automatically as part of incident response, which the incident trigger handles by running the playbook on incident creation. Alert triggers suit playbooks reacting to individual alerts without incident grouping.

Scheduled trigger

Why it fails: A scheduled trigger runs the playbook at fixed times, so it cannot react to the Sentinel incident and block the address promptly. Scheduled playbooks suit recurring maintenance tasks; incident-triggered automation, which fires when the alert is created, is required to block the attacker's IP for 24 hours.

Action trigger

Why it fails: An action trigger fires when a specific action is taken, not when an alert is raised, so it cannot initiate the playbook from the Sentinel incident itself. It suits scenarios where a playbook runs on demand or from a manual action within an incident, rather than automatic alert-driven response.

Reviewing group membership assignments

Why it fails: ID Protection surfaces risk detections and risk-based conditional access policies; group membership review is handled by access reviews in Microsoft Entra ID Governance. It is tempting because both concern identity hygiene, but reviewing assignments addresses entitlement creep, not sign-in risk.

Enforcing device compliance policies

Why it fails: Device compliance policies are enforced by Conditional Access, which evaluates device state at sign-in; Entra ID Protection instead detects and scores identity risk signals such as leaked credentials and anomalous sign-ins. It would be tempting when the requirement is blocking unmanaged devices from accessing resources, where Conditional Access is the correct control.

Resetting forgotten passwords

Why it fails: ID Protection detects and remediates risky sign-ins and compromised identities; self-service password reset is a separate Microsoft Entra ID feature. It is tempting because both reduce helpdesk load, but password resetting addresses credential recovery, not risk detection.

Cloud Workload Protection (CWP)

Why it fails: Cloud Workload Protection delivers runtime threat detection for servers, containers and databases, not posture assessment or recommendations. It would be correct if the requirement were defending workloads against active attacks rather than a unified secure-posture view across clouds.

Microsoft Secure Score

Why it fails: Microsoft Secure Score measures and recommends improvements for Microsoft 365 services and identities, not Azure, AWS and GCP resource posture. It would be the answer if the question asked about scoring an organisation's Microsoft 365 security configuration.

Regulatory Compliance Dashboard

Why it fails: The Regulatory Compliance Dashboard reports adherence to standards such as ISO 27001 or PCI DSS; it does not provide the continuous resource assessment and improvement recommendations described. It would be correct if the requirement were auditing compliance against a specific regulatory benchmark.

Generating custom reports with PowerShell for all activities.

Why it fails: While PowerShell cmdlets like `Search-UnifiedAuditLog` can retrieve audit data, generating comprehensive custom reports for *all* activities with advanced filtering, aggregation, or automated delivery is often limited by the default capabilities of Audit (Standard). More sophisticated, extensive, and automated reporting typically requires integrating with external Security Information and Event Management (SIEM) solutions or leveraging the advanced data export features of Audit (Premium).

Tracking when sensitivity labels are applied to documents.

Why it fails: Tracking specific, detailed events related to sensitivity labels, such as when a label is applied, changed, or removed from a document, generally requires the enhanced logging capabilities provided by Microsoft Purview Audit (Premium). While Audit (Standard) logs some basic file activities, the granular logging of sensitivity label interactions, crucial for comprehensive data governance and compliance auditing, is a feature primarily associated with Audit (Premium) due to its richer event schema.

Retaining audit logs for 2 years for compliance purposes.

Why it fails: Microsoft Purview Audit (Standard) has a default retention period of 90 days for audit logs, which is insufficient for compliance requirements demanding 2-year retention. To meet such long-term compliance obligations, organizations must leverage Microsoft Purview Audit (Premium), which offers customizable retention policies, including the ability to retain logs for up to 10 years to satisfy stringent regulatory mandates.

User Administrator

Why it fails: The User Administrator role provides extensive control over user accounts within Microsoft Entra ID, allowing the assigned technician to create new users, delete existing users, and manage all properties associated with user objects. While it certainly encompasses the ability to reset passwords, this role grants significantly more permissions than required for the stated task, including the dangerous capability to delete user accounts. Assigning this role would violate the principle of least privilege, as it provides unnecessary and potentially harmful administrative power.

Helpdesk Administrator

Why it fails: Helpdesk Administrators can reset passwords and manage support tickets, but they also have permissions to modify user properties such as email address and job title, which might be more than required, and they can also delete users in some scenarios.

Global Administrator

Why it fails: The Global Administrator role is the most privileged role in Microsoft Entra ID, granting unfettered access to all administrative features across all Microsoft cloud services, including the ability to manage all users, groups, applications, and even other administrative roles. Assigning this role to an IT support technician whose primary responsibility is password resets would be a severe security misconfiguration. This role provides far more power than necessary, posing a significant risk of accidental or malicious misuse, and fundamentally contradicts the principle of least privilege.