Design solutions that align with security best practices and priorities practice questions

Require multi-factor authentication

Why it fails: Requiring multi-factor authentication only adds an authentication factor; it does not restrict the type of client app (native vs. browser), so native client apps would still be allowed.

Require device to be marked as compliant

Why it fails: Requiring a device to be marked as compliant blocks all non-compliant devices, including unmanaged ones. This would prevent browser access from unmanaged devices, which contradicts the requirement.

Require hybrid Microsoft Entra ID joined device

Why it fails: Requiring a hybrid Microsoft Entra ID joined device blocks all non-joined devices, which includes unmanaged devices, thus preventing any access.

Azure Security Center dashboard

Why it fails: The Azure Security Center dashboard — now called the Defender for Cloud overview — is a general landing page that aggregates security posture, compliance, and alerts into a single view. It provides a high-level snapshot but does not offer a structured, prioritized list of recommendations ranked by severity and potential score impact. This makes it unsuitable for triaging which security controls to remediate first; that specific decision support is the role of Secure Score.

Inventory

Why it fails: Inventory in Defender for Cloud is a resource-centric view that lists all monitored machines, databases, and other assets with their trust status and software inventory. It is designed for asset visibility and management, not for presenting security recommendations or their relative priority. While it may highlight unpaired or unmonitored resources, it does not offer a scored, impact-weighted list of configuration gaps and therefore cannot guide remediation prioritization.

Security alerts

Why it fails: Security alerts are reactive notifications triggered by detections of actual or attempted attacks, such as suspicious PowerShell execution or anomalous sign-in activity, based on correlation of events across the environment. They are time-sensitive and demand immediate investigation, not proactive hardening actions. Because they represent active or latent threats rather than configuration gaps or missing best practices, they are not a source of prioritized security recommendations and cannot be used to plan long-term posture improvements.

Enable encryption at rest for all storage accounts

Why it fails: Encryption at rest, including Azure Storage Service Encryption (SSE) using AES-256, protects data confidentiality while persisted to disk. It does not inspect, filter, or control inbound/outbound traffic between virtual networks, subnets, or hosts. Defense-in-depth spans physical, perimeter, network, identity, and data layers; storage encryption belongs to the data layer, so it cannot satisfy the network-layer requirement of this question.

Enable Azure Firewall on all subnets

Why it fails: Azure Firewall is a stateful, managed network firewall offering L3-L7 filtering, FQDN-based rules, and threat intelligence, but it is designed to be deployed centrally in a hub virtual network, not on every subnet. Attaching it to every subnet would require complex user-defined routes and does not align with Azure's hub-spoke architecture; NSGs already provide subnet-level stateful filtering. The two required actions—DDoS Protection and NSGs—are the essential network layers; adding Azure Firewall on all subnets is unnecessary, cost-prohibitive, and technically incorrect.

Use managed identities for Azure resources

Why it fails: Managed identities for Azure resources provide an automatically rotated service principal that applications use to securely authenticate to Azure services like Key Vault or Storage, eliminating embedded credentials. This is an identity and access management capability that limits authorization, not a mechanism that filters, inspects, or segments network traffic. Because the question asks specifically for network-layer defense-in-depth actions, managed identities address identity-layer threats (e.g., credential theft) but not the network attack surface.

Data

Why it fails: Data is an essential resource that Zero Trust is designed to protect, but it is not one of the three core components in this specific question's correct set. In the Microsoft framework, the components of Identity, Device, and Network act as the enforcement points, while data is the protected asset that relies on those pillars for access control. Data classification, labeling, and encryption are important additional layers, but they do not represent a fundamental component on the same level as the selected trio. Therefore, Data is incorrect for this question.

Applications

Why it fails: Applications are another important layer within the broader Zero Trust architecture, but they are not among the three components sought here. In Microsoft's approach, applications are secured through policies that leverage identity and device signals, making them a downstream beneficiary of the core pillars rather than a primary component. The correct set—Networks, Devices, and Identities—forms the foundation for enforcing access to any application, while applications themselves are the resources being accessed. Hence, Applications is a wrong answer in the context of this question.

Regulatory Compliance Dashboard

Why it fails: Regulatory Compliance Dashboard provides a high-level view of how well your environment meets specific compliance standards such as CIS, ISO 27001, and NIST. It focuses on tracking which controls are satisfied or violated, and it offers evidence and policy mappings for auditors. It does not let you query or rank vulnerabilities by threat context, so it is not a vulnerability prioritization tool.

Secure Score

Why it fails: Secure Score is a built-in metric that summarizes your overall security posture as a percentage by aggregating the status of every recommendation from Defender for Cloud. While it helps you track which remediation actions would improve your score, it does not enable multi-factor queries or detailed threat-based filtering of individual vulnerabilities across resources. It is a health indicator, not a vulnerability prioritization and investigation tool.

Adaptive Application Controls

Why it fails: Adaptive Application Controls is a security control that uses machine learning to create allowlists of known-executable files on your Azure VMs, blocking unknown or malicious binaries from running. It protects against application-based threats and malware, but it does not discover, analyze, or prioritize software vulnerabilities in your workloads. Its purpose is runtime application control, which is distinct from vulnerability management and prioritization.

Set the automation level to 'Full - automatically remediate all threats'

Why it fails: Full automation executes every remediation action automatically, including high-impact operations such as isolating a device, disabling a user account, or quarantining critical files, with no human gate. In Defender XDR, this setting bypasses the Action Center approval workflow, so a false-positive alert could trigger destructive changes across the environment. The requirement to 'require approval for high-severity remediations' is explicitly a Semi-level behavior; Full would exceed the requested governance and introduce operational risk.

Set the automation level to 'No automated remediation'

Why it fails: Choosing 'No automated remediation' disables Automated Investigation and Response (AIR) entirely, so every threat—even low-risk items like spam or adware—will wait for manual triage and manual action. This removes the benefit of XDR's machine-learning-driven investigations, increases mean-time-to-respond (MTTR), and lets minor incidents escalate while an analyst is busy. The requirement explicitly wants automated containment for high-severity alerts; with no automation, there is no containment at all, and no approval step because nothing is automatically proposed.

Create a custom automation rule in Microsoft Sentinel

Why it fails: Microsoft Sentinel is a separate cloud-native SIEM, not the engine that powers Defender XDR's Automated Investigation and Response; the automation level you need is configured under Defender XDR's Settings → Microsoft 365 Defender → Automated investigation and response. Creating a custom automation rule in Sentinel would only orchestrate alerts within that SIEM, and while Sentinel can ingest Defender XDR signals, it does not change how AIR behaves inside Defender XDR. Attempting to use Sentinel for this purpose would introduce integration latency and duplicate effort, and it would not satisfy a security requirement that directly references Defender XDR's native automation settings.

Conditional Access policies requiring device compliance

Why it fails: Conditional Access policies requiring device compliance are access control mechanisms that evaluate whether a device meets compliance requirements before granting access to resources. They can block or allow access, but they do not perform any data wipe action, whether selective or full. While non-compliant devices can be flagged, the actual removal of corporate data is a separate Intune action that this policy type cannot initiate. Therefore, this option does not satisfy the need to selectively wipe corporate data from a lost device.

Device configuration profiles

Why it fails: Device configuration profiles in Intune deliver settings to devices, such as password requirements, restricted app usage, Wi-Fi, VPN, and email configurations, but they do not contain any data removal actions. They are used to establish the device's security posture and feature settings, not to isolate or purge corporate data from applications. Since the scenario calls for selectively wiping corporate data, this option is irrelevant because it lacks the ability to delete or identify managed application data.

Device compliance policies

Why it fails: Device compliance policies evaluate the device's high-level security and health state, such as jailbreak status, OS version, and encryption, to determine if it is compliant with organizational standards. When a device becomes non-compliant, Intune can trigger actions like sending notifications or, after a grace period, executing a full device wipe (remote wipe) that erases everything on the device, including personal data. This is not selective data wiping; it wipes the entire device, which overreaches the requirement to remove only corporate data while preserving personal data.

Use a third-party AI gateway to sanitize prompts

Why it fails: A third-party AI gateway for prompt sanitization is not natively integrated with Copilot for Security, so it cannot intercept or inspect the tool's traffic without significant custom development. Even if it could, sanitization only addresses user-supplied input and fails to protect data that Copilot automatically retrieves from connected APIs and data sources. This approach also introduces extra latency, operational complexity, and would not align with Microsoft's built-in compliance and governance features.

Disable Copilot for Security for all users

Why it fails: Disabling Copilot for Security for all users eliminates the data-exposure risk but also removes the tool's threat-hunting and incident-summarization capabilities, which defeats the purpose of the implementation. A complete kill switch is a reactive measure that provides no legitimate business value, unlike implementing granular RBAC and data boundaries that allow controlled, secure use. Since the company is actively implementing Copilot, a blanket disable should only be a temporary emergency stopgap, not a solution.

Train users to avoid entering sensitive information in prompts

Why it fails: User training on avoiding sensitive information in prompts is a good hygiene practice but is not a technical control, and it cannot prevent Copilot for Security from surfacing sensitive data that already exists within connected tools like Sentinel or Defender. It also depends on every analyst consistently exercising discipline, which is unreliable under time pressure during an incident. The secure design must assume prompts will contain sensitive context and enforce access control and data boundary measures at the platform layer.

Set up Information Barriers to prevent Copilot from accessing data across departments.

Why it fails: Information Barriers (IB) are a communication and collaboration control designed to prevent specific users or groups from interacting with each other across Teams, chats, or shared files. They do not modify or filter the data sources that Microsoft 365 Copilot uses for retrieval grounding, because Copilot operates on the user's effective SharePoint/OneDrive permissions and sensitivity labels, not on IB segment policies. In short, IB can stop a user from chatting with another department, but it cannot stop Copilot from returning content from that department if the user already has access to it.

Configure Data Loss Prevention (DLP) policies to block sensitive data from being used in prompts.

Why it fails: Data Loss Prevention (DLP) policies are built to inspect and protect content when it is in transit or at rest, such as email messages, documents, and endpoints. While newer DLP capabilities can scan Copilot prompts and responses for high-confidence sensitive patterns, they do not prevent Copilot from consuming sensitive data as source material; if a user has read access to a file, Copilot can use it regardless of DLP rules. Thus, DLP is a content control, not an access-control layer, and it cannot block sensitive data from being included in Copilot’s grounding context.

Enable Purview Audit to monitor Copilot interactions.

Why it fails: Microsoft Purview Audit records a technical log of events such as Copilot search queries, file accesses, and AI response generations, but it is inherently detective and reactive—attacks or inappropriate activities are logged only after they occur, and unauthorized access would already have taken place by the time an auditor reviews the log. Audit does not contain any control plane for enforcing permission boundaries, device posture, or geolocation restrictions; it provides evidence, not prevention. Therefore, while useful for compliance and incident forensics, Purview Audit cannot prevent or restrict Copilot access.

Deploy Azure Firewall in each cloud environment to filter traffic.

Why it fails: Azure Firewall is not involved in compliance assessment or configuration enforcement.

Deploy the Log Analytics agent to all VMs in the multi-cloud environment.

Why it fails: The Log Analytics agent is not required for compliance assessments.

SMS one-time passcode

Why it fails: SMS one-time passcode is not passwordless because it is intended as an additional verification factor after the user has already submitted their password. The user must still enter the password as the first factor, and the OTP is a short-lived shared secret delivered over the phone network, not a key-based proof of possession. SMS OTP is also vulnerable to SIM-swapping and phishing, so it cannot be considered a passwordless authentication method for Entra ID.

App passwords

Why it fails: App passwords are legacy credentials generated specifically for applications that cannot support modern authentication, such as those using older protocols or that do not integrate with conditional access. Each app password is a static, generated secret that effectively substitutes for the user's real password, so it does not eliminate the password requirement and fails the definition of passwordless. They also bypass MFA prompting and introduce persistent secrets that are deprecated in modern Microsoft Entra ID configurations.

The policy assignment is scoped to a management group that does not include the web app's subscription.

Why it fails: The scenario explicitly states the policy is assigned to the subscription that contains the web app, so a management-group scope that excludes that subscription cannot be the cause. Even if the assignment were at a management group, Azure Policy applies to all descendant subscriptions unless explicitly excluded, and the symptom here is not a scope filter but a missing assessment reference. The web app appears compliant because the existenceCondition cannot locate the custom assessment, not because the policy never applies.

The policy definition has a syntax error in the 'existenceCondition' field.

Why it fails: The exhibit shows a well-formed existenceCondition: it uses the standard 'field', 'equals', and 'name' operators, and the resource type is correctly qualified as Microsoft.Security/assessments/subAssessments. Azure Policy performs schema validation at definition creation time, so a syntax error would likely prevent the definition from being saved or assigned. Moreover, the behavior of all resources showing 'Compliant' is consistent with a valid definition that references a nonexistent assessment, not with a syntactic failure.

The web app is not running and therefore not assessed.

Why it fails: Azure Policy evaluates resources based on their Azure Resource Manager metadata, not on their runtime power state, so a stopped web app is still evaluated by the policy engine. Even if the web app is running, the sub-assessment resource would still be absent because the custom assessment must exist in Defender for Cloud before any per-resource assessment records can be generated. The real issue is the missing assessment definition, and changing the web app's run state would not make that assessment appear.

Data loss prevention (DLP) policies in Microsoft Purview

Why it fails: Data loss prevention (DLP) policies in Microsoft Purview are incorrect because they focus on content inspection and protection, scanning emails and documents for sensitive data patterns like credit card numbers or personally identifiable information, then applying actions such as blocking or encryption. They do not analyze user behavior, geolocation, or the temporal relationship between sign-in events, so they cannot detect impossible travel or other behavioral anomalies. Their purpose is safeguarding data at rest and in transit, not detecting account compromise through unusual activity.

Session policies in Microsoft Defender for Cloud Apps

Why it fails: Session policies in Microsoft Defender for Cloud Apps are incorrect because they enforce real-time access controls on user sessions, such as blocking downloads, restricting uploads, or requiring step-up authentication, based on conditions like IP address or device risk. These are preventive measures that act when a session is already flagged as risky, but they do not establish a behavioral baseline or detect deviations like impossible travel after the fact. They mitigate risk during a session, whereas anomaly detection identifies suspicious patterns based on historical behavior.

App permission policies in Microsoft Entra ID

Why it fails: App permission policies in Microsoft Entra ID are incorrect because they manage OAuth application permissions, governing which apps can access resources and granting consent based on risk criteria like high-privilege scopes or publisher verification. These policies evaluate the trustworthiness of applications, not user sign-in patterns or travel speed, so they have no mechanism to detect impossible travel or other behavioral anomalies. They address the risk of malicious applications, not the risk of compromised user accounts.

Microsoft Defender XDR automated investigation and response

Why it fails: Microsoft Defender XDR automated investigation and response is a built-in SOAR-like capability for Microsoft 365 Defender incidents, but it is limited to native Defender product alerts and predefined response actions. It cannot execute custom Logic Apps workflows, integrate with third-party security tools, or handle non-XDR signals like custom data connectors in Sentinel. Thus it is not a replacement for Sentinel playbooks in a security orchestration architecture.

Power Automate cloud flows

Why it fails: Power Automate cloud flows can automate generic business workflows and could technically be triggered from Sentinel alerts, but they are not the native playbook engine used by Microsoft Sentinel. Sentinel playbooks are exclusively designed as Azure Logic Apps logic apps, which appear directly in the Sentinel Playbooks blade and support security-specific connectors and incident context variables. Standalone Power Automate flows lack the governance and integration with Sentinel's incident trigger that Logic Apps provides, so this is not the correct platform for SOAR in Sentinel.

Microsoft Purview Compliance Manager

Why it fails: Microsoft Purview Compliance Manager is a governance and risk solution for assessing compliance posture against regulatory frameworks, not a SOAR platform. It provides a compliance score, control mapping, and evidence management for audits, but it has no mechanisms for receiving security alerts, executing remediation workflows, or orchestrating incident response actions. Since the question asks about implementing a security orchestration, automation, and response solution in Sentinel, Compliance Manager is entirely unrelated to automated playbook execution.

Microsoft Defender for Cloud Apps

Why it fails: Microsoft Defender for Cloud Apps is a cloud access security broker that provides shadow IT discovery, session controls, and data loss prevention across SaaS applications, but it does not perform network micro-segmentation. A Zero Trust network strategy relies on splitting the network into isolated zones with granular traffic rules, which is beyond the scope of a CASB. It governs application-layer access and data flows, not the underlying network connectivity between resources.

Microsoft Intune

Why it fails: Microsoft Intune is an enterprise mobility and device management solution that ensures endpoints meet compliance policies (e.g., OS patch levels, encryption) and can feed compliance status into Conditional Access. However, Intune itself does not segment network traffic or enforce per-connection access rules at the packet or flow level. It influences access indirectly through device posture, but the actual network segmentation requires separate infrastructure like Azure Firewall or virtual network security groups.

Microsoft Sentinel

Why it fails: Microsoft Sentinel is a cloud-native SIEM and SOAR tool that ingests security telemetry, detects threats, and orchestrates incident response (e.g., automated playbooks), but it does not act as an access control enforcement point. In a Zero Trust architecture, Sentinel provides visibility and alerts on suspicious activity post-event, yet it cannot dynamically block or allow a user's network access request at the time of authentication. Access control prerequisites are simply outside its function.

Microsoft Purview Audit

Why it fails: Microsoft Purview Audit provides a chronological record of user and admin activities across Microsoft 365, such as file access, permission changes, and sign-ins, but it does not scan, classify, or inventory data across repositories. Its purpose is forensic investigation and compliance auditing, not discovering sensitive data assets. Consequently, it cannot fulfill a data discovery requirement.

Microsoft Purview eDiscovery

Why it fails: Microsoft Purview eDiscovery is designed for legal and investigative workflows, allowing you to search content locations for relevant documents, place them on hold, and export them for case review. It does not perform proactive, classification-based scanning of data assets nor maintain a data catalog. Thus, it is not used for discovering sensitive data in a governance or compliance sense.

Microsoft Purview Information Protection

Why it fails: Microsoft Purview Information Protection focuses on classifying and protecting data by applying sensitivity labels, encryption, and usage restrictions based on policies. Although it relies on discovery results to know where to apply labels, it does not itself scan or inventory data across sources; its role is enforcement rather than discovery. Therefore, it is not a discovery solution.

Use Azure ExpressRoute to connect West Europe to East US

Why it fails: Azure ExpressRoute provides a private, dedicated network path between West Europe and East US, so it can reduce latency and improve connection reliability. However, it does not alter the fundamental regional placement of the Sentinel workspace—the existing workspace remains in East US, and all log data must still traverse the inter-region network boundary. ExpressRoute pricing includes per-GB data transfer charges for cross-region traffic, so you would still pay significant egress costs on every log ingested into the East US workspace. It also does not address data sovereignty or compliance if the company's European data must remain within West Europe.

Configure data collection rules to filter logs at source

Why it fails: Data collection rules (DCRs) in Microsoft Sentinel / Azure Monitor can filter or transform logs at the source, which reduces the total volume of data sent to the workspace. While this lowers the overall data transfer expense, it does not eliminate inter-region transfer costs entirely—any data that passes the filters and is sent to the existing East US workspace still incurs per-GB egress charges for crossing regions. Moreover, aggressive filtering can drop security-relevant events, reducing Sentinel's detection coverage and potentially creating blind spots. The core issue remains the geo-location of the workspace, not just the volume of logs.

Use the existing workspace; inter-region costs are negligible

Why it fails: Claiming that inter-region costs are negligible for an existing East US workspace is incorrect. Azure data transfer charges apply to inter-region inbound/outbound traffic, and for high-volume log ingestion—which is common in Security Information and Event Management (SIEM) scenarios—the cumulative per-GB egress cost can become substantial. Additionally, Microsoft Sentinel pricing includes both analytics charges and data transfer; the transfer cost is not waived regardless of the log volume. There is also a latency and reliability factor: sending security telemetry across continents adds delay and potential data egress bottlenecks, which can degrade time-to-detection and increase the cost of operations.

Use a single security vendor for all solutions

Why it fails: MCRA explicitly advocates a defense-in-depth strategy that integrates the best capabilities from multiple security vendors rather than forcing a single-vendor consolidation. A single vendor cannot cover every layer of the MITRE ATT&CK kill chain, so relying on one stack introduces monoculture risk where a common vulnerability or misconfiguration weakens the entire security posture. Instead of vendor unification, the reference architecture emphasizes telemetry interoperability, layered protections, and the ability to mix specialized point products across identity, endpoint, network, and cloud.

Block all legacy authentication protocols

Why it fails: MCRA does not prescribe an outright block of all legacy authentication protocols; it recommends a risk-based reduction strategy. Legacy protocols like NTLM and basic authentication lack support for modern controls such as MFA and conditional access, but a universal ban can break mission-critical or compatibility-dependent scenarios. The guidance is to progressively deprecate these protocols, deploy compensating protections, and migrate to modern methods like OAuth 2.0 and certificate-based authentication, rather than applying a blunt one-size-fits-all block.

Require multifactor authentication for all users

Why it fails: MCRA is context-based and does not mandate MFA for every single user or scenario, despite MFA being a critical control. The architecture directs conditional access policies to apply stronger authentication methods like MFA primarily to high-risk users, privileged roles, and sensitive actions, while lower-risk access may use adaptive or step-up authentication. A blanket requirement for all users at all times is operationally disruptive and unnecessary, as it ignores the risk signals from user behavior, device compliance, and location that MCRA explicitly wants organizations to leverage.

Disable sign-in logs to reduce storage costs

Why it fails: Sign-in logs are a mandatory source of evidence for security monitoring, incident investigation, and compliance audits, so disabling them to save storage costs directly undermines your ability to detect unauthorized access or credential replay. These logs feed cloud-native services like Entra ID Identity Protection and Microsoft Sentinel, where anomalies such as impossible-travel sign-ins or risky authentications are surfaced; without them, you lose critical visibility and forensic coverage. Instead of disabling logs, you should archive them to a low-cost storage account or export them to your SIEM, preserving audit history while optimizing costs.

Allow users to create Microsoft 365 groups without approval

Why it fails: Permitting unrestricted group creation causes serious security and governance problems because any user can spin up groups that grant access to sensitive Teams, SharePoint sites, or other resources, leading to data sprawl and accidental oversharing. Without an approval workflow or naming policy, the organization loses visibility over group membership, external user invitations, and lifecycle management, which complicates eDiscovery, access reviews, and insider-risk investigations. A best practice is to restrict group creation to a defined set of security groups and to regularly run access reviews to clean up orphaned or over-permissioned groups.

Assign Global Administrator to all users for simplicity

Why it fails: Making every user a Global Administrator drastically violates the least-privilege principle and multiplies the attack surface, since each of those accounts holds unrestricted control over the directory—including the ability to alter security policies, read all data, or permanently exfiltrate tenant information. If any single one of those over-privileged accounts is compromised through phishing or credential stuffing, the attacker gains domain-wide administrative capability and can even disable the MFA that was protecting other accounts. The proper design is to grant roles using least privilege, enforce just-in-time elevation with Privileged Identity Management (PIM), and reserve Global Administrator only for permanent break-glass accounts.

Microsoft Entra ID and Azure Policy

Why it fails: Microsoft Entra ID (formerly Azure AD) is an identity provider for users and applications, handling sign-in, authentication, and authorization with OAuth, SAML, and OpenID Connect—not for the device attestation protocols (e.g., TPM or X.509) used by IoT hardware. Azure Policy enforces resource compliance rules and tags across Azure resources, but it does not perform device enrollment or validate firmware state. Therefore, this combination would not secure the IoT devices themselves, as it lacks the capability to provision hardware identity or detect device-level threats.

Azure Sphere and Azure Security Center

Why it fails: Azure Sphere is a highly secure platform for microcontroller units (MCUs) with integrated Pluton security hardware and a custom Linux OS, so it only applies to a narrow subset of IoT devices—not the broad range of sensors, PLCs, or gateways in a manufacturing plant. Azure Security Center (now Microsoft Defender for Cloud) provides unified security management for cloud workloads like VMs and PaaS, but it does not provision devices into an IoT Hub or perform firmware validation specifically for IoT fleets. Thus, while this approach improves security for Sphere-based MCUs, it omits the core provisioning function and fails for non-MCU IoT devices.

Microsoft Intune and Azure Automation

Why it fails: Microsoft Intune is a unified endpoint management (UEM) service primarily for laptops, phones, and workstations using MDM/MAM protocols, and its IoT support is limited to platforms like Windows IoT—not the heterogeneous embedded devices typically found on a factory floor. Azure Automation is a service for orchestrating runbooks and configuration management within Azure, not for registering devices in an IoT Hub or monitoring device security posture. This pairing addresses manageability and cloud automation but leaves out both secure device enrollment and dedicated IoT threat detection, so it would not fulfill the security requirement.