Select Two (Multi-Select) Questions

Microsoft Purview External Identities

Why it fails: External Identities is for B2B collaboration, not data classification.

Microsoft Purview Compliance Manager

Why it fails: Compliance Manager helps manage compliance activities, not data scanning.

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.

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.

Enable basic authentication for all apps

Why it fails: 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 it fails: 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 it fails: 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.

Allow external sharing for all SharePoint sites

Why it fails: Broadly enabling external sharing on every SharePoint site drastically expands your tenant's attack surface and increases the risk of unauthorized data exfiltration. Each site should have sharing policies tailored to its content sensitivity, using guest access controls, expiration times, and conditional access to limit external collaboration safely.

Disable multifactor authentication for users who access from trusted IPs

Why it fails: Trusted IP addresses are an incomplete security boundary because they can be spoofed or used from an already compromised endpoint, and excluding them from MFA creates a direct bypass of your strongest authentication control. Conditional Access policies that exempt a location should still require additional checks like device compliance or risk-based assessment to avoid undermining identity security.

Allow all third-party apps to access Microsoft 365 data

Why it fails: Granting blanket access to all third-party apps is an authorization worst practice: legitimate apps may request broad Office 365 Graph permissions that exceed their functional need, and malicious apps can exploit OAuth consent to exfiltrate data. You should enforce app consent policies, audit app permissions continuously, and use app governance to allow only vetted, least-privilege integrations.

Trust but verify

Why it fails: The phrase 'trust but verify' is often cited as a security model, but Zero Trust rejects the notion that any entity can be initially trusted. In practice, trust but verify still grants an implicit level of trust based on network location or prior authentication, which can be exploited through lateral movement. Zero Trust mandates that no subject is trusted a priori; every request for a resource goes through continuous identity validation, device attestation, and policy evaluation. Therefore, trust but verify is not a key component; it is a legacy fallback that retains a window of implicit trust.

Implicit trust for internal traffic

Why it fails: Assuming internal traffic is implicitly trusted is a fundamental flaw because it treats the network perimeter as an unbreakable boundary. Even if a user or device resides on the corporate LAN, an attacker who has compromised one node can move laterally to other systems without re-authentication. Zero Trust flattens the network and requires the same level of verification for internal and external access requests. By eliminating implicit trust inside the network, the blast radius is contained and each interaction is challenged.

Rely on a strong perimeter

Why it fails: Relying on a strong perimeter assumes that the network boundary is the only line of defense, and once inside, trust is maintained. In modern hybrid and multi-cloud environments, there is no single physical perimeter: users access resources from anywhere, and resources live on-premises, in the cloud, and at the edge. Zero Trust operates under the assumption that the perimeter has already been breached, and it applies identity-based policies directly to individual resources and data. Thus, relying on a strong perimeter is not a component of Zero Trust; it is the legacy model Zero Trust seeks to replace.

Data Loss Prevention (DLP) policies

Why it fails: DLP policies detect and block sensitive data in motion or at rest but do not govern retention periods or deletion. It is tempting because DLP is a core Microsoft Purview compliance feature, and it is the correct choice when the requirement is preventing sensitive information from leaving the organisation, not lifecycle management.

Audit logs

Why it fails: Audit logs record user and admin activity for investigation, but they neither retain content in place nor delete it on a schedule, so they cannot enforce retention or deletion obligations. Audit logging is the right choice when the requirement is visibility into who accessed what, not lifecycle management of the data itself.

eDiscovery

Why it fails: eDiscovery identifies, holds and exports content for legal cases, but it does not apply organisation-wide retention or deletion rules to workloads. It is the correct tool for litigation and investigation workflows, where preserving and producing specific items matters, rather than meeting ongoing regulatory retention schedules across Microsoft 365.

Data loss prevention (DLP) policy

Why it fails: Data loss prevention (DLP) policies enforce protective actions such as blocking, restricting, or auditing data sharing, but they do not apply sensitivity labels. DLP is focused on preventing unauthorized transmission of sensitive data, not on classifying or labeling content for metadata purposes. Even if a DLP policy can detect sensitive info types, it cannot assign a sensitivity label to a document.

Retention label

Why it fails: Retention labels are designed to govern data lifecycle by specifying how long content is kept and whether it should be deleted after that period. They do not convey sensitivity level nor apply classification markings; a document can have both a retention label and a sensitivity label independently. For sensitivity classification, you need a sensitivity label rather than a retention label.

Trainable classifier

Why it fails: Trainable classifiers use machine learning to recognize content based on examples and patterns, rather than exact custom-defined rules. They are useful for identifying categories like resumes or source code, but they do not allow you to define a precise numeric pattern for a specific label. Consequently, they are not suitable when you need to match a bespoke pattern for sensitivity classification.

Microsoft Defender for Office 365

Why it fails: 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 it fails: 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.

Disable self-service password reset for users

Why it fails: Self-service password reset (SSPR) is a security enhancement, not a convenience feature to disable. When disabled, users are forced to contact the help desk, which creates opportunities for social engineering and leaves passwords stale or reused. SSPR integrated with MFA and registration policies actually strengthens identity verification by providing a self-service channel that enforces strong password requirements and reduces the likelihood of compromised credentials being used.

Synchronize all on-premises user accounts to Microsoft Entra ID

Why it fails: Synchronizing every on-premises account to Entra ID indiscriminately expands the attack surface by giving each account a cloud identity that can be targeted. Many on-premises accounts are legacy service accounts, disabled users, or non-person accounts that rarely need cloud access yet become exploitable footholds. Best practice is to sync only active accounts that require Entra ID capabilities, apply scoped filtering, and continuously remove stale identities to minimize lateral movement and credential theft risk.

Azure Front Door

Why it fails: Azure Front Door is a global HTTP/S load balancer and web application firewall, not a data-path tunneling or encryption service. It routes and accelerates web traffic at Layer 7 but does not establish an IPsec or MACsec encrypted tunnel between your on-premises network and Azure. Therefore it cannot secure site-to-site or private network traffic.

Azure Traffic Manager

Why it fails: Azure Traffic Manager is a DNS-based traffic load balancer that directs inbound requests to healthy endpoints based on routing methods like priority or performance. It operates only at the control plane by returning DNS answers and does not carry, tunnel, or encrypt any user data traffic. Consequently, it provides no confidentiality or integrity protections for site-to-site communication and is not a valid security mechanism.

Azure CDN

Why it fails: Azure CDN caches and accelerates delivery of static and dynamic content by replicating it to edge points of presence. It is not a site-to-site connectivity or encryption service; even when HTTPS is used, that only protects the client-to-edge segment, not a tunnel between your on-premises network and Azure. Thus, it lacks the capability to secure private network traffic between locations.

Create a DLP policy that blocks deletion

Why it fails: A Microsoft Purview DLP policy is designed to detect and prevent unauthorized sharing or leakage of sensitive data across endpoints, services, and on-premises locations. It does not intercept or control deletion operations on existing records, because deletion management falls under retention and disposition policies, not DLP rules. Attempting to block deletion through DLP would not enforce a retention period; the underlying record could still be deleted by the user or system without any administrative alert or block. Therefore, it is incorrect for ensuring records are kept for 7 years.

Apply a sensitivity label to the records

Why it fails: Sensitivity labels classify content by business sensitivity (for example, General or Confidential) and can apply encryption, visual markings, or access restrictions. They do not specify a retention duration or deletion behavior; these are separate properties managed exclusively by retention labels in Purview. Applying a sensitivity label alone leaves the record free to be deleted prematurely, as it carries no time-based enforcement. Hence, it does not fulfill the 7-year retention requirement.

Use a trainable classifier to identify records

Why it fails: Trainable classifiers are machine learning models in Purview that recognize content types (e.g., contracts, invoices) and can automatically assign a label to matching items. Even if a classifier accurately identifies a record, it only determines what the content is; it has no built-in authority to retain it for a certain number of days or years. The classifier must be configured to apply a retention label, and it is the retention label, not the classifier, that actually enforces the 7-year period. Therefore, using a classifier alone is insufficient and incorrect in this context.

Use perimeter-based security.

Why it fails: Use perimeter-based security is a traditional network security model that establishes trust based on whether a user or device is inside the corporate firewall. Zero Trust explicitly rejects this model because it assumes the network boundary is the primary security barrier and treats everything inside as trusted, which fails against insider threats, compromised credentials, and lateral movement. In a Zero Trust architecture, network location never confers trust, so perimeter-based security is an outdated and insufficient approach for modern threat environments.

Trust internal network.

Why it fails: Trust internal network is the incorrect notion that traffic originating from within the corporate LAN or VPN is inherently safe and requires no additional verification. Zero Trust operates on the principle that the network is always hostile, and every request must be verified regardless of its source. Trusting the internal network ignores threats like a compromised endpoint or an insider actor, allowing attackers to move laterally without impedance. This approach directly contradicts Zero Trust's requirement to never trust any network implicitly.

Trust but verify.

Why it fails: Trust but verify is a flawed principle because it implies an initial baseline of trust that is then subject to verification, aligning with traditional security models rather than Zero Trust. Zero Trust's correct mantra is 'never trust, always verify,' meaning trust is never assumed; it is earned only after continuous authentication, authorization, and validation of the user, device, and session. Even after verification, a user's access is not permanently trusted, so 'trust but verify' fundamentally misrepresents the dynamic, per-request trust evaluation in Zero Trust.

Identity protection and risk detection

Why it fails: Identity Protection is in Entra ID.

Endpoint detection and response

Why it fails: EDR is part of Defender for Endpoint.

Microsoft Entra Domain Services

Why it fails: Microsoft Entra Domain Services (formerly Azure AD DS) provides a managed domain in the cloud with Windows Server AD features such as domain join, Group Policy, LDAP, and Kerberos/NTLM authentication. It is not a synchronization tool; instead, it consumes synchronized identities from Entra Connect or creates its own managed domain for cloud-only resources. This option is wrong because its function is to host legacy applications requiring AD protocols, not to replicate identities from on-premises Active Directory to the cloud.

Microsoft Entra ID Protection

Why it fails: Microsoft Entra ID Protection is a cloud-based security service that uses machine learning to detect risky sign-ons and user behaviors, such as impossible travel, leaked credentials, and anomalous activities. It is not connected to on-premises directory synchronization; its role is to generate risk reports and trigger conditional access policies for remediation. This option is incorrect because it addresses identity security and threat protection, not the replication or synchronization of directory objects.

Microsoft Entra application proxy

Why it fails: Microsoft Entra application proxy (now part of Microsoft Entra ID) is an application access service that publishes on-premises web applications to external users through an external endpoint, providing secure remote access without requiring a VPN. It does not perform any directory synchronization; it simply routes authenticated requests to backend applications using connectors installed on-premises. This option is wrong because its focus is application publishing and access control, completely separate from the identity synchronization workflow.

Deploy Azure Firewall to block all inbound traffic.

Why it fails: Azure Firewall controls network layer access by blocking inbound traffic, but it does not prevent ransomware from executing on a VM once the attacker has compromised a legitimate service or user account. Ransomware often spreads via outbound connections, email attachments, or vulnerability exploitation that bypasses simple inbound rules. A firewall is a preventive control, not a detection or recovery control, so it cannot protect against internal execution or lateral movement.

Configure Azure Site Recovery for all VMs.

Why it fails: Azure Site Recovery (ASR) is designed for disaster recovery, replicating VMs to a secondary region for failover during outages. It is not a backup service and does not provide granular, immutable restore points that can be used to recover individual files or VMs after a ransomware attack. ASR replicated copies are also vulnerable if the primary and secondary environments are compromised together, and ASR does not offer WORM protection to prevent encryption or deletion by malicious actors.

Assign Azure Policy to require encryption at rest.

Why it fails: Requiring encryption at rest via Azure Policy protects data confidentiality by ensuring that stored data is unreadable without a decryption key, but it does nothing to stop ransomware from encrypting the active filesystem on a running VM. Ransomware attacks target the integrity and availability of data, not confidentiality, so the files are still encrypted by the attacker and held for ransom. Encryption at rest is a complementary control, not a direct mitigation for ransomware execution or data extortion.

Deploy Microsoft Intune to control app permissions on mobile devices

Why it fails: Intune's app protection policies (MAM) can restrict data transfer between managed apps, but they don't inspect content or generate DLP incident reports. This addresses device app permissions, not the DLP detection and reporting requirement. Intune lacks Purview's DLP policy matching, alerting, and incident management capabilities.

Implement Conditional Access policies to block external sharing of sensitive data

Why it fails: Conditional Access evaluates sign-in risk and session constraints, not data content. It cannot classify sensitive information or prevent a user from sharing a document externally; it only gates access at authentication time. DLP incident reporting is outside its scope.

eDiscovery (Premium)

Why it fails: eDiscovery (Premium) is incorrect because it is engineered for legal investigation and litigation, not GDPR compliance. While it can preserve, hold, search, and collect content in-place for a legal matter, it lacks the purpose-built DSR workflow, such as the ability to handle deletion requests with the required response timelines and audit trails. Its keyword and query-based search may find some data about an individual, but it does not classify personal data or enforce GDPR rights across an enterprise.

Insider Risk Management

Why it fails: Insider Risk Management is incorrect for GDPR compliance because its function is to detect, score, and investigate potentially malicious user activities such as unauthorized data exfiltration, IP theft, or policy violations. It looks at user behavior and risk indicators inside the organization, not at the existence or handling of personal data belonging to data subjects. GDPR obligations like DSR responsiveness and data minimization are not addressed by this security-focused tool.

Communication Compliance

Why it fails: Communication Compliance is not a GDPR compliance requirement because it is designed to monitor communications (email, Teams, Yammer, third-party platforms) for policy issues like inappropriate content, harassment, or regulatory recordkeeping breaches. It can detect keywords or sensitive-information types, but its output is a workflow for supervisory review and remediation of policy violations, not a mechanism for honoring data subject rights or managing personal data inventories. There is no capability for filing, tracking, or completing GDPR data subject requests within Communication Compliance.

Enable Azure Monitor for containers.

Why it fails: Azure Monitor for containers collects performance metrics, logs, and inventory from nodes, pods, and containers, providing observability into cluster health and application performance. While it can help detect security-relevant anomalies after the fact, it is a monitoring and diagnostics tool rather than a preventive or enforced security control. It does not authenticate users, authorize actions, isolate workloads, or manage secrets, so enabling it alone does not improve the cluster's overall security posture.

Enable the HTTP application routing add-on.

Why it fails: The HTTP application routing add-on automatically deploys an ingress controller and creates a public DNS zone to route HTTP/HTTPS traffic to services in the cluster. It is a developer convenience for quickly exposing applications during development, not a security feature. It does not provide authentication, TLS policy enforcement, or network-level protection; in fact, it can increase the attack surface by making services publicly reachable without attendant security controls such as Web Application Firewall or API gateway policies.

Enable the cluster autoscaler.

Why it fails: The cluster autoscaler automatically adjusts the number of agent nodes in the nodepool based on pending pods and resource utilization. It is a horizontal scaling mechanism that focuses on capacity and cost management, not on security. Enabling it does not affect authentication, authorization, network policies, or workload identity, and it cannot protect the cluster from unauthorized access or malicious traffic.

Azure DevOps

Why it fails: Azure DevOps is a software collaboration suite for source control, CI/CD pipelines, and work tracking; it is not a telemetry source for security events. As a result, Sentinel provides no built-in data connector for Azure DevOps, and any integration would require a custom HTTP Data Collector API or a Logic App workaround. Since the question asks for supported data sources via standard connectors, Azure DevOps is not a correct answer.

Power BI

Why it fails: Power BI is a business intelligence and reporting service, not an endpoint, server, or application that produces security event logs. Sentinel has no native data connector for Power BI, and the service is designed for visualizing data rather than acting as a source of security telemetry. Trying to treat Power BI as a Sentinel data source would misrepresent both products and is therefore not a valid choice.