Hard Difficulty Questions

Microsoft Purview Compliance Manager

Why it fails: Microsoft Purview Compliance Manager is a regulatory compliance assessment and management tool within the Microsoft Purview portfolio. It helps organizations track their compliance posture against standards like ISO 27001, NIST, and GDPR, using assessments, improvement actions, and evidence collection. It does not perform any code scanning or infrastructure-as-code analysis; its scope is administrative and procedural compliance, not the technical validation of IaC templates.

Microsoft Sentinel

Why it fails: Microsoft Sentinel is a cloud-native security information and event management (SIEM) and security orchestration, automation, and response (SOAR) solution. It ingests logs, telemetry, and alerts from across the hybrid environment to detect threats, investigate incidents, and automate responses. Sentinel operates on runtime and operational data after resources are deployed; it does not perform static analysis or scanning of Infrastructure as Code templates, which occurs pre-deployment in the pipeline.

Microsoft Defender for Cloud Apps

Why it fails: Microsoft Defender for Cloud Apps is a cloud access security broker (CASB) designed to provide visibility, control, and data protection for software-as-a-service (SaaS) applications. It monitors user activities, file sharing, anomaly behavior, and app permissions to enforce policies like session control and conditional access. It does not scan Infrastructure as Code templates; its focus is on governing cloud app usage and securing data, not on validating the configuration of infrastructure code before deployment.

Records Management

Why it fails: Records Management applies retention and disposition labels to declared records; it does not scan content to detect personal data or apply classification labels. Auto-labelling in SharePoint Online uses sensitivity labels with auto-labelling policies. Records Management would be correct when governing the retention lifecycle of regulatory records.

eDiscovery

Why it fails: eDiscovery identifies and preserves content for legal cases; it does not apply classification labels during normal operation. Auto-labelling of personal data in SharePoint Online requires sensitivity labels with auto-labelling policies, which scan content and apply labels. eDiscovery would be correct when collecting evidence for litigation or investigations.

Data Loss Prevention policies

Why it fails: DLP policies detect sensitive information and block or warn on sharing, but they do not apply classification labels to documents. The requirement is automatic labelling, which sensitivity labels with auto-labelling policies perform. DLP would be correct when preventing exfiltration of personal data across Exchange, SharePoint and Teams.

Power Automate with user account

Why it fails: Power Automate is designed for business process automation and isn't the execution engine for Microsoft Sentinel playbooks; Sentinel automation rules invoke Logic Apps workflows natively. Furthermore, authenticating with a user account means relying on interactive credentials that can expire, require MFA, and lack least-privilege access for runtime operations, making it unsuitable for autonomous security automation.

Azure Automation with service principal

Why it fails: Azure Automation runbooks can execute PowerShell or Python scripts, and a service principal provides non-interactive authentication; however, Sentinel playbooks are not implemented as Automation runbooks. Triggering a runbook from Sentinel would require custom webhooks, extra credential rotation for the service principal's secret or certificate, and still lacks the rich connector ecosystem and native incident trigger that Logic Apps provides.

Azure Functions with API key

Why it fails: Azure Functions is a valid compute option for custom security logic, but it is not Sentinel's integrated playbook service, which expects Logic Apps workflows. An API key is a static secret that must be securely stored and rotated, offers no identity-based permissions, and can be accidentally exposed in headers or source control, making it far less secure and manageable than a managed identity in the Sentinel playbook context.

Advanced eDiscovery

Why it fails: Used for legal investigation, not ongoing data security compliance.

Data Lifecycle Management (retention policies)

Why it fails: Important for governance but not a direct security control for CCPA/GDPR.

Assign RBAC roles to each subscription owner.

Why it fails: Assigning RBAC roles to each subscription owner governs who can access and manage resources, but it does not enforce the actual configuration or compliance of deployed workloads. Subscription owners could provision resources that violate corporate standards without any automatic guardrails or policy enforcement. RBAC is identity-based access control, not a mechanism for evaluating resource configuration, lacking the centralized inheritance and exemption capabilities of policy assignments. Thus, it fails to implement a proactive cloud governance strategy.

Create separate Microsoft Entra ID tenants for each business unit.

Why it fails: Creating separate Microsoft Entra ID tenants for each business unit introduces administrative silos that fragment identity management, conditional access policies, and resource governance across the organization. Collaboration and resource sharing between business units would require complex cross-tenant trust, Microsoft Entra B2B configurations, or manual federation, increasing operational overhead and security risk. Additionally, organizations lose the ability to enforce unified compliance through a single management group hierarchy, since each tenant is its own independent governance boundary. This approach is unnecessarily complex and does not align with centralized governance best practices.

Use Azure Blueprints with locked permissions.

Why it fails: Azure Blueprints package reusable resource groups, role assignments, policies, and ARM templates to create consistent environments, but they are scoped to a single subscription and primarily support initial deployment, not ongoing governance changes. While Blueprints can include deny assignments to lock permissions, they lack the dynamic, centralized exemption capability that management group-level policy assignments provide. Exceptions to a blueprint's resources require editing or reassigning the blueprint, which is rigid and not scalable for continuous compliance across many subscriptions. Moreover, Blueprints are deprecated in favor of deployment stacks, but neither replaces the need for a management group hierarchy with Azure Policy.

Microsoft Sentinel's Anomalous Activity rule

Why it fails: Sentinel's Anomalous Activity rule uses machine learning to baseline normal behavior but has no awareness of Microsoft Defender for Endpoint's device risk score. These rule types inspect ingested telemetry to spot statistical outliers, not the specific RiskScore field that classifies a device as High. Even if MDE data is connected, an anomaly rule will not fire deterministically for the condition DeviceRiskScore == 'High'.

Microsoft 365 Defender connector with an NRT query rule

Why it fails: The Microsoft 365 Defender connector, now superseded by the Microsoft Defender XDR connector, ingests alerts and raw events, but pairing it with an NRT query rule is a weak architectural choice. NRT rules evaluate near-real-time with a one-minute window and restrict certain KQL operators and joins, making them brittle for correlating device identity with a risk score. A scheduled query can reprocess a wider time window and reliably join DeviceInfo to capture the latest risk classification, which NRT cannot guarantee.

Microsoft Defender for Cloud connector with a Fusion rule

Why it fails: The Microsoft Defender for Cloud connector integrates security alerts from cloud workload protection (VMs, containers, storage) and has no visibility into endpoint devices managed by Microsoft Defender for Endpoint. The Fusion rule engine correlates alerts across connectors to detect multistage attacks; it cannot simply read a single device's RiskScore to decide whether to alert. Querying that connector for endpoint risk fields would fail because the DeviceInfo schema is not present.

Configure a conditional access policy to block access from untrusted networks when credit card numbers are detected

Why it fails: Conditional Access evaluates signals like user risk, device compliance, and network location to govern access to applications, but it cannot inspect file contents for credit card numbers. Detecting sensitive data requires classification through Microsoft Purview sensitivity labels or DLP policies. Thus, this option conflates network access control with content-based data protection and would not apply encryption or sharing restrictions.

Create a Microsoft Purview Data Loss Prevention (DLP) policy that blocks external sharing when credit card numbers are detected

Why it fails: A DLP policy is designed to prevent unauthorized transmission of sensitive data by inspecting content at the point of sharing, such as email or SharePoint, and can block external sharing. However, DLP does not inherently apply persistent encryption or require the content to retain protection after it leaves the environment. The question specifically asks for protection via sensitivity labels, making this an incomplete approach.

Use Azure Information Protection to label and protect files with credit card numbers

Why it fails: Azure Information Protection (AIP) was the predecessor to the current Microsoft Purview Information Protection solution. While some AIP clients remain, Microsoft has consolidated labeling and protection capabilities into Purview sensitivity labels, and new deployments should use Purview. Relying on AIP alone is outdated and would not provide the fully integrated auto-labeling and sharing-blocking controls described in the correct answer.

Deploy Azure Firewall in one central hub region and route all traffic through it

Why it fails: Placing a single Azure Firewall in one hub region forces all cross-region traffic through a distant inspection point, adding measurable latency to every flow and creating a regional blast radius where a failure in that hub disrupts all regions. Azure's recommended pattern is to deploy firewalls per hub so inspection stays local and availability is preserved.

Use Network Security Groups (NSGs) on subnets to filter traffic

Why it fails: NSGs operate at layers 3 and 4 only, applying allow/deny rules based on source/destination IP, port, and protocol without ever peering into packet payloads. They can block traffic to and from subnets but cannot identify malware signatures, perform intrusion prevention, or log session-level application layer activity, so traffic that passes NSG checks is sent without further inspection.

Deploy a third-party NVA in a hub-and-spoke topology with a single hub

Why it fails: A single third-party NVA in a single hub-and-spoke hub still concentrates all inspection in one location, so the hub is both a scaling bottleneck and an availability dependency; should that appliance fail, every region loses east-west and north-south inspection. It also demands manual high-availability clustering, complex user-defined routes, and separate license patching across each instance, with no native regional redundancy.

Windows Autopilot deployment profile

Why it fails: Autopilot is for initial provisioning.

Configuration profile in Intune

Why it fails: Configuration profiles configure device settings, not compliance.

Create more analytics rules to cover additional scenarios.

Why it fails: Adding more analytics rules increases the number of alerts generated, often with low fidelity, which can lead to alert fatigue and cause analysts to miss critical indicators. The investigation graph focuses on correlating entities and relationships in existing alerts, not on generating additional signals. Therefore, this approach does not streamline the investigation flow; it merely adds noise that obscures true attack paths.

Configure automation rules to automatically classify incidents.

Why it fails: Configuring automation rules to automatically classify incidents assigns labels such as 'true positive' or 'false positive' based on predefined conditions, which is a post-incident triage action. While it improves response efficiency by prioritizing work, it does not equip analysts with a visual, interactive view of how entities are connected. Classification does nothing to reveal the relationships that are central to understanding the scope of an attack, so it fails to enhance investigation effectiveness.

Increase data retention for all log tables.

Why it fails: Increasing data retention for all log tables extends the time period for which raw logs are stored in the analytics workspace, but it does not alter how entity relationships are modeled or presented during an investigation. The investigation graph relies on current entity enrichment and graph inference, not on the availability of older logs. This change adds significant storage cost without improving the analyst's ability to correlate entities, making it an inefficient solution for this scenario.

Deploy Azure Arc on each EC2 instance

Why it fails: Deploying Azure Arc on each EC2 instance is incorrect for this scenario because Azure Arc requires the Connected Machine agent to be manually installed on every instance before it can be managed; it does not perform native discovery or automatic onboarding of AWS resources. Microsoft Defender for Cloud's AWS connector is purpose-built to discover EC2 instances without per-instance manual setup, so this approach adds operational overhead and still does not itself provide Defender security assessments.

Use AWS Systems Manager to push Defender workload

Why it fails: AWS Systems Manager is an AWS-native management service for patch baselines, Run Command, and State Manager, but it has no integration or capability to deploy or push Microsoft Defender for Cloud workloads onto EC2 instances. Defender for Cloud has its own agents (e.g., Azure Monitor Agent, Defender plans) and a dedicated multicloud connector path; there is no Systems Manager document or API that can install Defender extensions. Relying on Systems Manager would leave the workload unprotected by Defender.

Configure AWS Config rules to report to Defender

Why it fails: AWS Config rules provide compliance checks within AWS against resource configurations, but they are not an onboarding mechanism for Microsoft Defender for Cloud; there is no event subscription or reporting channel that forwards AWS Config results into Defender. The only supported integration path is the AWS connector in Defender for Cloud, which uses resource APIs and IAM roles rather than Config. Creating Config rules would give you AWS-native compliance data only, not Defender recommendations or security monitoring.

Use Azure OpenAI Service with default settings. Implement Microsoft Sentinel to detect threats. Use Azure Policy to enforce tagging of resources. Use Microsoft Entra Conditional Access to require MFA for access.

Why it fails: Default Azure OpenAI settings may retain prompts and completions for abuse monitoring unless configured otherwise; this violates data privacy for proprietary pharmaceutical research. Sentinel only provides post-hoc threat detection, and Azure Policy tagging is an operational governance control with no bearing on data leakage. Conditional Access MFA protects user credentials but cannot stop an authenticated researcher from pasting sensitive data into a prompt. This combination lacks a DPA, content filtering, and real-time exfiltration blocking.

Use Azure OpenAI Service with a private endpoint. Deploy Azure Information Protection to classify data. Use Azure Firewall to restrict access. Implement Azure DDoS Protection.

Why it fails: A private endpoint secures the network path to Azure OpenAI but does not prevent sensitive data from being transmitted in the prompt payload. Azure Information Protection is deprecated and not supported for scanning or labeling content flowing through managed AI services. Azure Firewall applies network-layer rules and is oblivious to prompt injection or content filtering at the application layer. DDoS Protection only ensures availability, so this plan inadequately addresses data governance and confirms the need for Purview and Defender for Cloud Apps.

Use Azure OpenAI Service with managed identity. Configure Conditional Access to restrict access by IP. Use Azure Monitor to track usage. Implement Azure Key Vault for API keys.

Why it fails: Managed identity and Azure Key Vault establish secure authentication and secret management, but they do not restrict what an authorized user can submit to the model. Conditional Access by IP controls network location but not the content of prompts or completions. Azure Monitor tracks usage metrics like tokens and request counts yet lacks visibility into the actual data payload for exfiltration detection. Without a DPA or configured content filters, there is no guarantee that prompt data is transient and not logged by Microsoft.

Store a client secret in Azure Key Vault and have the portal retrieve it at runtime to call the API.

Why it fails: Key Vault removes secrets from source code but the portal still handles a long-lived secret and must be granted access to the vault, expanding the attack surface. Secrets must be rotated manually or via automation, and any compromise of the portal's vault access exposes the API credential. This does not meet the no-secret and auto-rotation requirements.

Issue each portal instance a client certificate and configure mutual TLS between App Service and Azure Functions.

Why it fails: Mutual TLS can authenticate the caller, but managing certificate issuance, distribution, and rotation for App Service adds significant operational burden and does not use the platform's identity system. It also does not produce a token the Functions app can use for fine-grained authorization, so it is a weaker fit than a managed identity.

Configure IP restrictions on the Azure Functions app to allow only the App Service outbound IP addresses.

Why it fails: IP allowlisting restricts network origin but does not authenticate the caller; any workload sharing those egress addresses could call the API. It also fails the requirement that the portal prove its identity, and outbound IPs can change with scale or slot swaps, making the allowlist brittle and insecure.

Microsoft Entra Conditional Access with trusted locations policy

Why it fails: A trusted locations policy relies on IP address or named network ranges to allow or block access, so it is purely location-based and never evaluates signals such as impossible travel, anonymous IP addresses, or token replay. Because a compromised account can sign in from an approved corporate IP, this policy would grant that session without requiring step-up authentication. It also cannot bind the decision to the sensitivity of the specific data in SharePoint. For these reasons it does not meet the stated sign-in risk requirement.

Microsoft Entra Conditional Access with MFA for all SharePoint access

Why it fails: Forcing MFA on all SharePoint access is overbroad: it applies the same control to public team sites and to highly confidential research sites, causing unnecessary user friction and failing to prioritize risk. The policy has no dependency on Identity Protection's sign-in risk scores, so a low-risk session is challenged just as aggressively as a sign-in with clear anomalies. It also does not leverage authentication contexts, meaning the protection cannot be narrowed to only sensitive document libraries. Thus it is wrong because it is both too broad and not risk-based.

Microsoft Entra Identity Protection user risk policy with MFA

Why it fails: A Microsoft Entra Identity Protection user risk policy looks at the probability that the entire account has been compromised based on leaked credentials or historic behavioral telemetry, and then applies MFA or password change upon the next sign-in. This is a user-level, longitudinal risk assessment, not a per-sign-in evaluation of the current authentication event, so it cannot detect and respond to anomalies like token replay at the moment they occur. Moreover, it has no concept of authentication context, so it cannot vary the requirement based on whether SharePoint data is labeled as sensitive. These two limitations make it the wrong pairing for sign-in-risk-driven, data-sensitive protection.

Microsoft Purview Information Protection

Why it fails: Information Protection is the labeling and classification engine in Microsoft Purview. It applies confidentiality labels and can enforce encryption or usage restrictions, but it does not monitor user behavior after labeling. Alerting on external sharing is outside its scope because it lacks the ability to evaluate sharing permissions or generate security alerts.

Microsoft Purview Audit

Why it fails: Microsoft Purview Audit records user and admin activities but is a passive logging service that does not evaluate patterns or generate proactive alerts. To detect external sharing, an organization must export or stream these audit logs to a tool like Sentinel and write a query. The Audit log itself provides the data, not the alert.

Microsoft Purview auto-labeling policy

Why it fails: Auto-labeling policies enable automatic application of sensitivity labels to content based on rules or sensitive information types. These policies act at creation or modification time and do not inspect or react to files after they are labeled. Sharing events occur after labeling and are not monitored by auto-labeling; therefore, this policy cannot generate alerts for external sharing.

Deploy the app on a multi-tenant App Service plan, enforce HTTPS only with TLS 1.2, use a system-assigned managed identity to access Azure SQL Database, and configure TLS/SSL certificates from Azure Key Vault.

Why it fails: A multi-tenant App Service plan provides no VNet isolation or private endpoints, failing requirement three. It is tempting because system-assigned managed identity and Key Vault certificates satisfy other items, but only an ASE v3 delivers the dedicated, network-isolated hosting FedRAMP High demands.

Deploy the app on an ASE v3 in a VNet, enforce HTTPS only with TLS 1.2, use a user-assigned managed identity to access Azure SQL Database, and configure TLS/SSL certificates from App Service certificates.

Why it fails: App Service certificates are stored in the App Service resource, not Azure Key Vault, so requirement five fails. Key Vault is tempting because it centralises secrets and supports customer-managed keys, but App Service certificates cannot satisfy the mandated Key Vault certificate management for custom domains.

Deploy the app on an ASE v3 in a VNet, enforce HTTPS only with TLS 1.2, use a service principal to access Azure SQL Database, and configure TLS/SSL certificates from Azure Key Vault.

Why it fails: A service principal authenticates with a client secret or certificate stored outside the app, whereas managed identity removes that credential entirely. Service principals are tempting for automation across tenants, but requirement four explicitly mandates managed identity for Azure SQL Database access.

Use Microsoft Entra ID Protection to detect compromised accounts and automatically block access.

Why it fails: Microsoft Entra ID Protection only evaluates sign-in risk and user risk; it can challenge or block authentication for compromised accounts, but it has no file-level or malware-scanning capability. Ransomware typically arrives as an email attachment or via a direct upload from an already-authenticated user, so a healthy identity session won't stop the initial infection. Therefore, while it reduces the attack surface, it does not provide ransomware detection or file recovery.

Enable Microsoft Endpoint DLP and configure file policies to block encrypted files.

Why it fails: Microsoft Endpoint DLP is a data classification engine that inspects content for sensitive information types and can restrict actions like copy, paste, or upload, but it does not inspect for malware or detect encryption as a malicious event. If you block all encrypted files, you would break legitimate use cases like BitLocker-protected documents or user-applied encryption, and ransomware that encrypts files inside SharePoint would not be blocked because a DLP policy would never be triggered. Its purpose is data loss prevention, not endpoint protection or recovery from ransomware.

Configure Microsoft Purview auto-labeling to apply a 'Ransomware' label and then block all labeled files.

Why it fails: Microsoft Purview auto-labeling applies classification labels based on rules such as sensitive info types, keywords, or trainable classifiers, and those labels can invoke protection like encryption or external-sharing block. It does not perform malware scanning, and it cannot distinguish between a file encrypted by ransomware and a file that is simply formatted in a compressed or encrypted container (for example, a .zip or a PDF). Blocking every file that carries a 'Ransomware' label would cause broad business disruption and still fail to stop an attack, because ransomware does not modify data classification labels.

Entity behavior analytics (UEBA)

Why it fails: UEBA builds behavioral baselines for users and entities, surfacing anomalous activity through analytics, but it does not ingest or synchronize alerts or incidents from Microsoft Defender XDR. It relies on already-collected data such as sign-in logs and requires separate data connectors to be configured. Therefore, while UEBA enriches detection, it cannot serve as the synchronization mechanism the organization needs.

Automation rule to trigger playbook

Why it fails: Automation rules can trigger playbooks to run automated response actions when incidents are created or updated, but they are not the source of incident synchronization. Without the data connector, there are no Defender XDR incidents in Sentinel to trigger anything. Playbooks and automation rules operate on incidents that already exist, so they are optional components used after ingestion, not the required mechanism for synchronization.

Create an Azure Policy initiative that automatically remediates non-compliant resources

Why it fails: Azure Policy is designed for continuous compliance and governance of Azure resources, not for security incident response. An initiative that remediates non-compliant resources uses effects like 'modify' or 'deployIfNotExists' to bring resources back to a desired configuration, but it cannot receive a Sentinel incident or dynamically isolate a VM as part of a threat-remediation workflow. It also lacks the ability to create a ticket in your ITSM tool or correlate the action with a specific security alert. Thus, while useful for posture management, it is entirely the wrong mechanism for this incident-response requirement.

Create a Microsoft Sentinel analytics rule that runs a KQL query and automatically sends an email to the security team

Why it fails: A Microsoft Sentinel analytics rule is a detection control that runs KQL queries to identify suspicious activity and generate alerts or incidents; it is not an action-execution engine. While you can configure the rule with an automated email notification, sending an email is only a passive alert, not an automated response that isolates the VM or opens a ticket in your ITSM tool. The proper pattern is to use an analytics rule for detection and then have an automation rule trigger a playbook to perform the response, because the analytics rule itself cannot orchestrate multi-step remediation actions.

Create an Azure Automation runbook that runs on a schedule to check for threats and isolate VMs

Why it fails: An Azure Automation runbook that runs on a schedule uses a polling model, checking for threats at fixed intervals rather than reacting instantly when Sentinel creates an incident. This is not event-driven and will inevitably have detection latency, and it cannot correlate its operations with the specific incident that triggered response. Moreover, the runbook would need extensive custom code to integrate with Sentinel entities and your ITSM system, whereas a Sentinel playbook provides native connectors and automation rules. Scheduled checks can also isolate a healthy VM or miss a rapidly evolving attack, making it an inadequate and inefficient incident-response solution.

The sign-in is blocked only if sign-in risk is also high

Why it fails: This option incorrectly assumes that user risk and sign-in risk must both be High to trigger the block. In the exhibit, the sign-in risk condition is not configured at all, leaving it empty and therefore unevaluated. The user risk condition is set to High and mapped directly to the block grant control, so the sign-in is blocked based solely on user risk, not on a combination of both risk types.

The sign-in is allowed because sign-in risk is not high

Why it fails: This option misreads the policy's risk handling by suggesting that a non-High sign-in risk would allow the sign-in. Since the sign-in risk condition is not configured, the policy does not evaluate sign-in risk in any capacity; it treats the condition as not applied. The user risk condition, set to High with a block action, is the decisive factor and forcibly blocks the sign-in regardless of sign-in risk status.

The user is prompted for multi-factor authentication

Why it fails: No multi-factor authentication (MFA) grant control exists in the conditional access policy shown in the exhibit; the only access control configured is 'Block access' when user risk is High. Grant controls in Conditional Access define what must be satisfied to allow access, and since none are listed, MFA is not prompted. Instead, the policy's block action overrides any potential grant behavior, producing a hard denial of the session.