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

Require multi-factor authentication

Why wrong: 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 wrong: 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 Azure AD joined device

Why wrong: Requiring a hybrid Azure AD joined device blocks all non-joined devices, which includes unmanaged devices, thus preventing any access.

Azure Security Center dashboard

Why wrong: 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 wrong: 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 wrong: 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.

Anomaly rule

Why wrong: Anomaly rules rely on machine learning to establish a baseline of normal behavior and then flag deviations from that baseline. They are designed to detect unusual patterns or outliers rather than enforce a simple temporal condition like 'incidents between 2 AM and 4 AM'. Because they learn from historical data and adapt over time, they cannot be configured to trigger solely based on a fixed time-of-day schedule.

Fusion rule

Why wrong: Fusion rules are a security orchestration feature that automatically correlate multiple alerts from different security products (e.g., Microsoft Defender, Azure AD) to identify multi-stage attack chains. They require a combination of signals or events that together suggest a sophisticated attack, not a single condition. A time-of-day-only trigger would not satisfy the correlation logic that Fusion rules depend on, as they are designed to combine diverse telemetry rather than evaluate a standalone threshold.

NRT query rule

Why wrong: NRT (near-real-time) query rules are designed to run continuously or very frequently (every few minutes) to minimize detection latency, making them unsuitable for conditions tied to a specific time of day. They are meant for rapid response to events as they happen, not for scheduled evaluations that depend on the clock. Because they do not support a scheduled start or end time, they cannot enforce 'only between these hours' logic in the same way a scheduled query rule can.

Migrate VMs from classic to ARM

Why wrong: Migrating classic VMs to ARM modernizes the deployment model and improves access control by enabling finer-grained RBAC and better network security groups, but PCI DSS does not mandate a specific Azure deployment model. Compliance requirements such as 8.3.1 focus on actual security controls like MFA for privileged access, which are independent of the VM deployment type. Migration is a strategic modernization effort and does not remediate the immediate, auditable gap of missing MFA on administrative accounts, making it a lower priority for compliance response.

Enable vulnerability assessment on SQL databases

Why wrong: Enabling vulnerability assessment on SQL databases supports PCI DSS requirement 11.2, which requires regular scans and remediation, but it is a detect-and-report process rather than a direct preventive access control. The immediate compliance failure is likely a missing MFA control on owner accounts (8.3.1), not an absence of scanning capability. Additionally, vulnerability assessment requires ongoing triage and patching to be effective, while enabling MFA is a single configuration change that instantly reduces the risk of privilege escalation via compromised admin credentials, making it the more urgent action.

Enable diagnostic logs in Key Vault

Why wrong: Key Vault diagnostic logging supports PCI DSS requirement 10, which mandates audit trails for system components, but logging is a detective control that only records access events after they occur. It does not prevent unauthorized access, and an administrative account without MFA can be compromised before any log event is generated or analyzed. While necessary for complete compliance, enabling diagnostics is secondary to enforcing MFA because MFA actively blocks malicious access attempts and directly fulfills the specific administrative-access requirement that is currently failing.

Enable encryption at rest for all storage accounts

Why wrong: 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 wrong: 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 wrong: 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.

Microsoft Defender for Office 365

Why wrong: Microsoft Defender for Office 365 is a specialized security solution for email, attachments, Microsoft Teams, SharePoint, and OneDrive. It detects phishing, malware, and malicious links within collaboration and messaging workflows, but it does not monitor hybrid cloud infrastructure such as virtual machines, databases, or on-premises Active Directory. Therefore, it is not one of the three solutions that detect threats across hybrid environments.

Microsoft Intune

Why wrong: Microsoft Intune is a cloud-based endpoint management service that handles mobile device management (MDM) and mobile application management (MAM). It enforces compliance policies, manages OS and app configurations, and supports conditional access, but it does not analyze security telemetry or generate threat detection alerts. Intune is a management solution, not a detection solution, so it is incorrect for this question.

Enable basic authentication for all apps

Why wrong: Basic authentication sends user credentials in a trivially decodable base64 string and has no inherent support for MFA, making it a prime target for credential theft and replay attacks. Enabling it for all apps widens the attack surface across the tenant, because attackers can brute-force or spray passwords against any endpoint that accepts basic auth. The secure alternative is to disable basic authentication entirely and mandate modern authentication protocols like OAuth 2.0 with device-based capabilities, which support conditional access and token expiry.

Disable modern authentication for legacy protocols

Why wrong: Legacy protocols such as POP, IMAP, and SMTP AUTH cannot participate in conditional access or MFA, so forcing them to use modern authentication would actually be impossible — they would fall back to less secure authentication or break. Disabling modern authentication would leave these protocols unprotected, enabling attacks that exploit password-only authentication. Instead, the best practice is to leave modern authentication enabled and shut down legacy protocol endpoints, or enable legacy authentication with MFA only when absolutely necessary via OAuth 2.0 extension.

Allow all external sharing in SharePoint

Why wrong: Configuring SharePoint to allow unrestricted external sharing, especially with 'Anyone' links, permits anonymous access to files without requiring sign-in, making the data publicly discoverable and leaking sensitive information. Even restricting to authenticated guests without other safeguards can result in oversharing because users may unintentionally invite external parties to sensitive documents. SharePoint provides granular sharing controls such as domain allowlists, link expiration, access reviews, and guest expiration policies that should be enabled to minimize risk while still allowing legitimate collaboration.

Data

Why wrong: 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 wrong: 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.

Kubernetes cluster should be accessible only over HTTPS

Why wrong: While enabling HTTPS for the API server protects data in transit between clients and the control plane, it does nothing to verify the origin or legitimacy of container images scheduled onto nodes. Securing the API transport layer is a critical control, but it is orthogonal to image registry allowlisting, which is the subject of the policy requirement. Without an image allowlist, a compromised or misconfigured cluster could still pull and run a malicious image from an unapproved repository over an encrypted connection.

Kubernetes cluster should use internal load balancers

Why wrong: Configuring services with internal load balancers restricts network exposure to the virtual network, preventing direct inbound traffic from the public internet. However, this networking control is unrelated to the source of container images; an internal service can still be backed by pods running arbitrary images from unapproved registries. Image provenance and network exposure are independent security dimensions, so using internal LBs fails to satisfy a requirement that containers only use allowed images.

Kubernetes cluster should not allow privileged containers

Why wrong: Prohibiting privileged containers hardens the runtime environment by preventing pods from requesting extended host access, which mitigates container breakout and host compromise. Yet this control addresses runtime privileges, not image authorship: a non-privileged container can still run a vulnerable or malicious binary sourced from an unvetted registry. The requirement to allow only permitted images is enforced at admission, while privileged-container restrictions are a separate Pod Security Admission control.

Set 'kind' to 'BlobStorage'

Why wrong: The 'kind' property determines the storage account's service type and feature set, such as general-purpose v2, BlobStorage, or BlockBlobStorage. Changing it to 'BlobStorage' does not affect how the account handles HTTP vs. HTTPS or which TLS versions are accepted. The BlobStorage kind is a legacy option primarily for blob-only hot/cold access tiers; transport security is governed by 'supportsHttpsTrafficOnly' and 'minimumTlsVersion', not 'kind'.

Add 'networkAcls' with defaultAction Deny

Why wrong: Network ACLs with 'defaultAction' Deny restrict the source IP ranges or Azure Virtual Networks that can reach the storage account's endpoints. However, even if only trusted networks are allowed, the account could still accept HTTP requests from those networks unless 'supportsHttpsTrafficOnly' is explicitly set to true. Therefore, this control does not enforce HTTPS-only or any TLS minimum; it merely narrows the set of permitted clients.

Change 'sku.name' to 'Standard_LRS'

Why wrong: The 'sku.name' determines the replication strategy and performance tier, such as 'Standard_LRS' for locally redundant storage or 'Premium_LRS' for SSD-based accounts. Selecting 'Standard_LRS' has zero bearing on cryptographic-protocol settings; SKU and TLS/HTTPS are orthogonal properties in the resource model. This change would not satisfy the security requirement because it addresses data durability and capacity, not encryption in transit.

Regulatory Compliance Dashboard

Why wrong: 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 wrong: 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 wrong: 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.

An Information Barrier policy between departments

Why wrong: Information Barrier policies in Microsoft Purview are designed to prevent users in conflicting groups from communicating or collaborating, such as financial and trading teams. They inspect user relationships and segments, not file contents for credit card numbers, and they never apply encryption. This makes them a communication governance control, not a data classification or protection control for sensitive documents.

A retention label that deletes documents with credit card numbers after 90 days

Why wrong: A retention label governs the data lifecycle by specifying how long content is kept and when it must be deleted, typically for compliance or legal requirements. Deleting documents containing credit card numbers after 90 days does not classify the data nor encrypt it while it exists, leaving it unprotected during the entire retention period. Thus, it addresses disposition rather than protection or classification.

A Data Loss Prevention (DLP) policy that blocks sharing of credit card numbers

Why wrong: A Data Loss Prevention (DLP) policy is an enforcement control that identifies credit card numbers using sensitive info types and blocks actions like sharing them through email or cloud apps. However, DLP does not assign a classification label or encrypt the underlying file, so data remains unprotected at rest and when sharing is permitted. Blocking is a reactive safeguard, whereas the requirement demands proactive encryption as part of classification.

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

Why wrong: 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 wrong: 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 wrong: 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.

Workbooks

Why wrong: Workbooks are interactive dashboards built on Azure Monitor and Sentinel data; they provide rich visualizations and trend analysis but do not have any built-in logic to correlate separate alerts into a single incident. While a workbook can display multiple alerts side by side, it cannot automatically group them or create an incident, so it is not a mechanism for alert correlation.

Playbooks

Why wrong: Playbooks are automated response workflows (built on Azure Logic Apps) that execute actions on alerts or incidents, such as sending notifications, disabling compromised accounts, or opening a ticket. They are triggered after an alert or incident is generated and do not contain any native logic to correlate or group alerts together; their purpose is orchestration and remediation, not detection or incident synthesis.

Hunting queries

Why wrong: Hunting queries are proactive, investigator-initiated KQL queries used to search raw event logs for suspicious activity that existing detections may miss. They can produce bookmarks or livestream sessions but are not part of the alert pipeline and cannot automatically group alerts into incidents; they help discover threats but rely on analytics rules to transform findings into correlated incidents.

Conditional Access policies requiring device compliance

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: The Log Analytics agent is not required for compliance assessments.

SMS one-time passcode

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.