Microsoft Cybersecurity Architect (SC-100) — Questions 376–450

An auto-labeling policy in Microsoft Purview can automatically detect credit card numbers using sensitive information types or classifiers and then apply a sensitivity label that is configured with encryption. By specifying that the label be applied only when content is shared externally, the policy ensures that documents containing credit card data are encrypted upon external sharing, while internal collaboration remains unaffected. This satisfies the requirement for automatic, content-aware protection without user intervention, making it the correct solution.

Remediation policy in Microsoft Intune is a Proactive Remediation feature that pairs detection and remediation PowerShell scripts and runs them on managed Windows devices on a set schedule. When the detection script finds a rule violation, the remediation script automatically executes to restore the device to a compliant state. It reports execution results back to Intune, allowing administrators to verify fixes without manual intervention. This is the only option here that actively performs corrective actions rather than just evaluating or defining state.

Standard_LRS is a managed disk SKU but does not equal Premium_LRS, so the policy's notEquals Premium_LRS condition evaluates to true for any VM using it. This makes those VMs non-compliant because the policy mandates Premium_LRS for all managed disks attached to virtual machines. The disk size is not part of the condition, so every Standard_LRS disk, regardless of capacity, triggers the same non-compliance result.

The conditional access policy defines user targeting exclusively through the includeRoles array and omits the includeUsers array entirely. This means the policy only applies to sign-ins from users assigned to the specified directory roles, leaving every non-role user outside the policy scope. The absence of an includeUsers entry, such as the shortcut value 'All', prevents the policy from being universally enforced and is the root cause of the misconfiguration.

Microsoft Entra Privileged Identity Management (PIM) provides just-in-time privileged access to Azure AD and Azure resources, requiring activation with approval and MFA. It supports eligible assignments, time-bound activations, and comprehensive audit logs, directly fulfilling the requirement for JIT access with approval workflows and auditing.

Assigning an Azure Policy initiative that contains the built-in policy 'Secure transfer to storage accounts should be enabled' with a Deny effect is the correct preventive control. Azure Policy evaluates resource creation and update requests during the ARM API call, and the Deny effect rejects any storage account that does not have the 'Secure transfer required' property set to true, returning an error before the resource is provisioned. This ensures non-compliant storage accounts are never created, and assigning it at a management group or subscription scale provides consistent enforcement across the entire environment. An initiative bundles together multiple policies, enabling comprehensive compliance with frameworks like the Azure Security Benchmark while the Deny effect specifically blocks insecure configurations.

BGP local preference is a standard, AS-wide attribute used to select the preferred path for outbound traffic, with higher values (e.g., 200) being preferred over the default of 100. By enabling BGP on both connections and assigning a higher local preference to routes learned via ExpressRoute, both on-premises devices and (with appropriate configuration) peers will consistently prefer ExpressRoute for all traffic. When ExpressRoute fails and its routes are withdrawn, the VPN route automatically becomes the best path because it carries the lower local preference, enabling seamless and deterministic failover. This approach is platform-independent, unlike proprietary weight, and gives explicit control over the primary/backup relationship.

Microsoft Defender for Cloud is the correct choice because it includes built-in vulnerability scanning for container images in Azure Container Registry and other supported registries. It continuously scans images when they are pushed, detects known vulnerabilities using integrated CVE databases, and provides actionable remediation recommendations. Integrating this into a secure DevOps pipeline allows automated gating to block vulnerable images from reaching production.

Entitlement management with connected organizations lets external partners authenticate via their own identity providers while Microsoft Entra ID governs access through access packages. Lifecycle workflows automatically deprovision those accounts when partners leave their home organization, meeting the automatic removal requirement.

Creating Azure Policy initiatives—such as the built-in Microsoft Cloud Security Benchmark initiative—and assigning them to management groups and subscriptions is the correct approach because Defender for Cloud pulls its recommendations and regulatory compliance findings directly from these policy assignments. The assignments define audit, Deny, and DeployIfNotExists effects that enforce secure configuration continuously across native Azure resources and hybrid machines connected via Azure Arc. This model gives organizations centralized governance, automated remediation, and a clear audit trail for compliance evidence. It is the foundation that makes Defender for Cloud's recommendations actionable and repeatable.

Conditional Access evaluates each access request against signals — user risk, device compliance and location — and enforces grant or session controls accordingly, delivering the continuous, context-aware evaluation Zero Trust demands rather than relying on a one-off authentication event.

Under Azure DDoS Network Protection, if an attack triggers auto-scaling of protected resources, Microsoft automatically applies a credit for the incremental compute and bandwidth consumed during the attack window. This cost protection is provided by default for resources with DDoS protection enabled, ensuring that the necessary scale-out to absorb volumetric attacks doesn't cause an unexpected billing spike.

Legacy authentication protocols such as POP3, IMAP4, and SMTP do not support modern authentication and therefore cannot present additional MFA challenges or respond to Conditional Access grant controls. Azure AD treats these clients as unmanaged and typically exempts them from Conditional Access policies unless explicitly blocked via a separate legacy authentication policy. As a result, users relying on legacy clients can authenticate with only a password, explaining why MFA is being bypassed.

A compliance policy that mandates device encryption ensures that the storage medium (e.g., internal flash) is encrypted, typically using the hardware security module and a recovery key managed by the device, so that if the device is lost, the data is unreadable without the decryption key. This is a protective measure at rest; in addition, the compliance policy can trigger conditional access to block non-compliant devices, but the encryption itself is the core safeguard that prevents data exposure from physical access.

Compliance policies in Intune define the specific conditions a device must meet to be considered compliant, such as required OS versions, password requirements, encryption status, and threats detected by Mobile Threat Defense. Each device periodically uploads its health and configuration to the Intune service, which computes a compliant/non-compliant state. This state can then be consumed by Azure AD Conditional Access to allow or block access to emails, apps, and data based on real-time compliance. When a policy is combined with a Conditional Access policy requiring device compliance, non-compliant devices are blocked from accessing protected resources—making this the correct answer.

Microsoft Purview Data Loss Prevention (DLP) policies are the correct feature because they are purpose-built to detect sensitive data in real time and can trigger interactive policy tips in supported Microsoft 365 apps. When a user tries to share an email, document, or message that contains sensitive information, the DLP policy evaluates the content and displays a non-blocking tip or block action, educating the user and enforcing compliance. Unlike classification-only tools, DLP policies directly implement the user-notification workflow described in the question.

Defender for Office 365 runs anti-malware and detonation-in-sandbox scanning on files uploaded to SharePoint, OneDrive, and Microsoft Teams, immediately removing known malicious files. It also continuously monitors for ransomware activity with heuristic and machine-learning rules, then alerts you to impacted files. Version history and the recycle bin act as a self-service recovery mechanism, letting you restore a previous unencrypted version of a file with a few clicks, even after mass encryption. This combines prevention, detection, and remediation—exactly what the question asks for.

Azure App Service authentication can be configured to use Microsoft Entra ID, which is required for user authentication.

CloudAppEvents is the correct table for investigating SaaS application activity because it aggregates sign-in and activity transactions from Defender for Cloud Apps across thousands of cloud apps, including Office 365, AWS, and Google Workspace. Each row contains user, device, IP address, and app-specific action metadata, allowing analysts to pivot from a suspicious identity or endpoint to cloud-side anomalies. This table is one of the five default tables in Defender XDR advanced hunting and is essential for end-to-end, cloud-inclusive threat hunting.

Microsoft Entra ID Conditional Access evaluates user identity, device compliance and sign-in context at every access request, and applies risk-based policies through signals such as user risk and sign-in risk. This continuous, context-aware evaluation is the core enforcement point of a zero-trust design.

Always Encrypted with secure enclaves is the correct solution because it provides true column-level encryption where plaintext values are never exposed to the Azure SQL Database engine. Client-side drivers encrypt data before transmission, and the database only sees ciphertext; secure enclaves (based on Intel SGX or Windows Virtualization-Based Security) enable confidential computing operations such as equality and pattern matching on encrypted columns without revealing plaintext to the engine. This accomplishes both at-rest and in-use column protection, which is exactly what the requirement asks for.

An Intune compliance policy enforces the minimum OS version, encryption and jailbreak or root detection requirements, while a Conditional Access policy requiring compliant devices blocks corporate app access for non-compliant devices and supports automatic remediation.

An Entra Conditional Access policy requiring a compliant device is the correct mechanism because it directly checks the device's compliance state as reported by Microsoft Intune at sign-in time. The policy evaluates device health attributes like encryption, jailbreak status, and threat detection, and can block access or grant access only when compliant. This is the standard zero trust control that enforces device compliance before granting access to applications or resources.

Automation rules are central to Sentinel's SOAR capabilities because they let you define automated incident orchestration—such as assigning ownership, changing status, or running a playbook—when an alert is triggered or an incident is created. They close the gap between detection and response by turning analytics alerts into coordinated actions across Office 365, Microsoft Entra ID, and third-party systems. Without automation rules, alerts would require manual triage and response, reducing Sentinel to a passive monitoring tool rather than an active, automated security operations platform.

Microsoft Purview Data Map is the correct choice because it provides automated scanning and classification of sensitive data across hybrid and multi-cloud environments, including on-premises, Azure, and other clouds such as AWS S3. Its data scanners can connect to Azure SQL databases and S3 buckets, inspect schemas and content, and apply classifications that feed into DLP policies. This makes it uniquely capable of discovering and mapping sensitive data at rest in non-Microsoft 365 sources, which is the core requirement here.

Azure Policy is the correct service for centrally managing and monitoring security policies because it provides a unified governance plane for creating, assigning, and managing policy definitions and initiatives at management group, subscription, or resource group scope. It continuously evaluates resources against your compliance rules using effects such as Deny, Audit, Append, and DeployIfNotExists, and it presents a compliance dashboard showing the state of your environment. Built-in initiatives like the Microsoft Cloud Security Benchmark are delivered through Azure Policy, making it the primary service for enforcing security and compliance standards across all Azure resources.

Microsoft Entra entitlement management is the correct approach because it is purpose-built for governing external access to resources in a B2B scenario. An access package can be created that contains a SharePoint Online site; when a partner user is assigned the package, they receive precisely the permissions defined — in this case read-only — and those permissions are enforced by SharePoint and Entra. The solution also provides built-in lifecycle management, such as expiration, approval workflows, and access reviews, ensuring access is time-bound and auditable, which aligns with a healthcare organization's privacy and compliance obligations.

Azure Policy for AKS uses built-in initiatives built on Gatekeeper/OPA to enforce pod security standards at admission control time, rejecting or auditing non-compliant workloads before they are created. This centralizes governance across multiple clusters and can apply effects like deny, audit, or mutate to ensure Pod Security Standards (baseline/restricted) are consistently enforced. As a right answer, it prevents misconfigured security contexts, hostPath mounts, or privileged containers that would otherwise violate policy.

The Azure Policy definition uses a condition that checks the storage account's networkAcls.defaultAction property, and because the effect is set to 'Deny', the resource provider rejects the create request before any storage account is provisioned. The deployment fails with a policy violation error, and no resource is created.

Auto-labeling policies scan content and apply retention labels when items match a sensitive info type, such as credit card numbers. This delivers automatic, condition-based labelling at scale, satisfying the requirement without relying on manual user classification.

Microsoft Defender for Cloud is the correct choice because it includes a built-in, agentless vulnerability scanner for container images stored in Azure Container Registry (ACR). When an image is pushed or pulled, Defender for Cloud automatically scans it using the Qualys scanner and matches findings against a continuously updated CVE database. The results provide severity levels, remediation guidance, and can be integrated into CI/CD gates via Defender for Cloud APIs or CLI to block deployment of images above a certain risk threshold. It also re-scans images on a regular basis to detect newly discovered vulnerabilities, providing both pre-deployment and ongoing protection.

Authentication Strengths is a Conditional Access grant control that lets an administrator define a policy requiring a specific set of acceptable authentication methods, such as FIDO2 security keys or certificate-based authentication. It evaluates the method actually used at sign-in and blocks sessions that do not meet the configured strength, making it the correct mechanism for enforcing phishing-resistant MFA on privileged accounts.

This query correctly identifies the specified brute-force pattern: it groups failed sign-in events (e.g., ResultType indicating failure) by user account, source IP address, and a 1-hour time bucket using bin(), then filters for groups where the failure count exceeds 10. That precisely matches 'accounts with more than 10 failed login attempts from the same IP within an hour.' It deliberately ignores successful logons and post-incident account states, which is exactly the described behavior.

To invoke a playbook in Microsoft Defender for Cloud, the automation action must be of type 'LogicApp' and contain the playbook's callback URL, not 'EventHub'. An EventHub action simply exports the event to an event hub for ingestion by external systems, whereas LogicApp directly triggers the playbook's workflow. Because the requirement is to run a playbook, the action type is the misconfigured property, and correcting it from EventHub to LogicApp is the necessary fix.

Fusion rules are built-in analytics rules in Microsoft Sentinel that use machine learning to correlate alerts from multiple Microsoft security products (e.g., Microsoft Defender for Identity, Defender for Office 365, Microsoft Entra ID Protection) into a single incident. The fusion engine maps alerts to MITRE ATT&CK stages, linking actions like initial access, lateral movement, and exfiltration into one coherent story. Because it automatically identifies multi-stage attack patterns without custom KQL, Fusion is the correct rule type for the organization's requirement to correlate multi-stage attacks.

Microsoft Entra application proxy is the correct choice because it publishes on-premises web applications to external users through an outbound connector installed on an internal server. The connector establishes an outbound connection to Microsoft Entra ID, eliminating the need for inbound firewall rules; users authenticate against Entra ID with support for MFA, conditional access, and modern protocols, after which requests are routed via the connector to the internal application. This enables secure remote access to legacy apps without a VPN.

This option correctly applies a dual-policy conditional access strategy that covers both managed and unmanaged device scenarios. The first policy grants access only when the device is either Intune-compliant or Microsoft Entra joined and passes health attestation, ensuring that managed endpoints meet security baselines. The second policy requires app protection policies for unmanaged devices, which enforce data-loss-prevention and secure app-level controls without requiring full device enrollment, thereby protecting corporate data across every access path.

Auto-labeling policies in Microsoft Purview scan locations such as SharePoint Online for sensitive information types like credit card numbers and apply the configured sensitivity label automatically, with no user action. This directly matches the requirement to detect and encrypt sensitive content at rest without interaction.

This statement is correct. The policy definition uses the 'modify' effect, which updates an existing resource in place. Specifically, it sets the `diskEncryptionSet.id` property on the OS disk to the customer-managed key encryption set identifier specified in the policy parameters. This action, performed during evaluation or via a remediation task, applies encryption to the OS disk without creating a new disk or deploying any additional resources.

Microsoft Purview Information Protection is the correct service for implementing a Zero Trust data protection strategy because it provides data classification, sensitivity labeling, and protection directly on documents and emails. It uses sensitive information types, trainable classifiers, and exact data match to automatically detect content and apply labels, which then can trigger encryption or access restrictions. Additionally, the Content Explorer and Activity Explorer give security teams visibility into labeled data, and the labels integrate across endpoints, cloud apps, and on-premises repositories.

Without a bin or bin_at, the query computes a single count over the entire 1-hour period, and every time the scheduled rule runs it re-counts all events in that sliding window, creating duplicate incidents. Binning by a fixed interval (e.g., 5m) groups events into distinct time buckets, so each event contributes to exactly one bucket and the rule can reference the previous run's bucket to avoid reprocessing. Use bin_at with a fixed reference point to align buckets across runs when the schedule offset matters.

Auto-labeling policies in Microsoft Purview scan items in SharePoint, OneDrive, and Exchange, and when they detect defined sensitive information types—such as credit card numbers—they automatically apply the specified sensitivity label to that content. These policies can first run in simulation mode to assess impact and then be enforced, ensuring consistent, touchless labeling across the organization. This is the correct answer because the question describes automatically labeling documents containing credit card data.

A playbook in Microsoft Sentinel is a collection of automated procedures built on Azure Logic Apps, enabling incident response actions such as isolating a device, disabling a user, or blocking an IP address. These playbooks contain the logic and steps that execute directly against security controls, and they can be triggered by alerts or incidents. This is exactly what is needed to design an automated response workflow.

Data classification and labeling are correct because GDPR requires you to know what personal data you hold, where it is stored, and how it is processed. Azure Purview Information Protection lets you classify and label files and emails based on sensitivity (e.g., Personal, Highly Confidential), which then enables automated protections like encryption or access restrictions. This labeling is foundational for data minimization, accountability (Article 5), and the ability to efficiently respond to data subject requests, making it a key GDPR enabler.

Entitlement management access packages bundle specific application assignments with an expiry, directly satisfying the 30-day external partner constraint. Time-limited access packages automatically revoke access at expiration, unlike conditional access policies, which govern session conditions rather than provisioning and lifecycle.

With `publicAccess: None`, Azure Storage rejects any anonymous request to the container, so unauthenticated clients cannot read or write data. Azure AD authentication is natively enabled for Blob Storage, meaning authorized users and applications can authenticate via their Azure AD identities without any additional configuration. This satisfies the requirement to block anonymous access while still allowing authenticated access.

Creating a custom analytics rule is the technically correct approach because analytics rules in Microsoft Sentinel evaluate telemetry at ingestion time and can dynamically assign incident severity by referencing data fields such as the RiskLevel attribute from Microsoft Entra ID Protection. By setting the Alert Severity to a value derived from RiskLevel (e.g., High if risk is medium, Higher if risk is high), the incident is created with the appropriate priority immediately, enabling efficient triage without further post-processing. This native, rule-based mapping is the only option among the listed alternatives that directly controls initial incident severity as the incident is generated from raw log data.

Microsoft Authenticator app with passwordless sign-in is the correct choice because it leverages the user's smartphone as a possession factor, using a cryptographic challenge-response protocol. When the user enters their username, the Authenticator app displays a number or a number match prompt; the user's approval signs the request with a private key stored in the device's secure enclave, eliminating the password entirely. This method is phishing-resistant, supports conditional access policies, and works seamlessly on iOS and Android, making it ideal for smartphone-centric users.

Deploying the Log Analytics agent (or its current replacement, the Azure Monitor Agent) is a foundational requirement for Microsoft Defender for Cloud to ingest operating system security events, audit logs, and vulnerability telemetry. Without this agent, Defender for Cloud cannot assess OS-level hardening or detect malicious activity, making the security baseline ineffective. This agent enables continuous monitoring, threat detection, and integration with Microsoft Sentinel, so it directly supports the threat protection baseline.

The Conditional Access policy explicitly assigns the 'High' user risk condition to the 'Block access' grant control, meaning any sign-in event where the user's risk level is assessed as High will be immediately denied. User risk is derived from identity protection signals such as leaked credentials or anomalous behavior, and once it meets the configured threshold, the policy's block action applies without regard to other conditions. In the exhibit, no sign-in risk condition is configured, so user risk alone is sufficient to trigger the block.

Retention policies in Microsoft Purview let you retain content for a defined period and then delete it automatically, directly satisfying regulatory retention and deletion obligations. They apply across Exchange, SharePoint, OneDrive and Teams without requiring manual intervention.

Event 4625 with Logon Type 3 is generated when a network logon attempt (e.g., SMB/NetBIOS) fails due to an invalid username or password, which is the classic signature of a brute-force password guessing attack. The combination of multiple sequential failed logon attempts originating from a single source IP and targeting a privileged account such as a domain administrator indicates that the attacker is systematically trying many passwords to crack the account. This is distinct from opportunistic scanning because the failures are concentrated on one high-value account, and if successful, the attacker could move laterally using the compromised credentials.

Microsoft Defender XDR is the correct answer because it is the integrated, cloud-native extended detection and response (XDR) platform that natively correlates alerts from Microsoft Defender for Endpoint, Office 365, Identity, and Cloud Apps. By combining signals across domains into a single incident queue, it performs the automatic cross-product correlation the company requires. Its machine-learning-driven analytics unify threat hunting and response without needing external SIEM logic.

Azure Site Recovery is the correct choice because it provides continuous, block-level replication of Azure VMs to a secondary region. It delivers a recovery point objective (RPO) in the range of minutes, well within the required 1-hour RPO, and offers orchestrated failover and failback with predictable recovery time objectives (RTO). This makes it the only listed option that is purpose-built for disaster recovery, not just backup or local redundancy.

Blocking the sharing of sensitive information is a core DLP enforcement action. In Microsoft Purview, you can configure DLP policies to block sharing via email (e.g., 'Block only people outside your organization'), block uploads to external sites, or block copy/paste to unsanitized apps. This action can be configured with an override option or a policy tip, directly preventing data loss. It is the definitive 'enforce' behavior for DLP scenarios.

Cross-Region Restore enables you to restore backup data to a paired Azure region, providing a robust disaster recovery posture when the primary region is unavailable. It is a critical component of a comprehensive backup strategy, as it ensures business continuity and geographic resilience for your VMs. While it does not directly address long-term retention, it complements immutable vault and Archive Tier by guaranteeing that your backup data is accessible even in a regional failure scenario.

Enabling the CIS Azure Foundations Benchmark in Defender for Cloud's regulatory compliance dashboard is the correct action because it automatically attaches a curated Azure Policy initiative containing the required policies and controls. The dashboard continuously assesses your Azure environment against CIS controls, provides a compliance score, and surfaces remediation recommendations. This directly supports the benchmark with minimal manual effort and ongoing visibility, fulfilling your organization's compliance monitoring requirement.

An automation rule is the native, direct mechanism for assigning incident ownership at creation time. You define a trigger condition (e.g., all incidents or specific severity) and add an action to set the owner to the senior SOC analyst; the rule runs automatically the moment an incident is created, ensuring immediate accountability without human intervention. This is the simplest and most scalable approach for a one-step assignment.

The Regulatory compliance dashboard in Microsoft Defender for Cloud is the correct tool because it continuously monitors subscribed cloud resources against a wide range of industry and regulatory standards (for example, PCI DSS, ISO 27001, SOC 2, and NIST). It provides a real-time compliance score, a control-by-control breakdown, automated evidence collection, and the ability to download authoritative PDF/CSV compliance reports. Unlike Azure Policy's raw policy compliance, this dashboard maps assessments directly to regulatory control gaps and maintains a standards-specific view, making it the purpose-built solution for continuous compliance assessment and reporting (e.g., PCI DSS).

Transparent Data Encryption (TDE) performs real-time I/O encryption and decryption of Azure SQL Database data and transaction log files, protecting data at rest without requiring changes to the application. The database engine writes encrypted pages to disk and decrypts them when they are read into memory, making the process completely transparent to clients. This is the only option listed that directly secures the database's stored sensitive data.

The investigation graph in Microsoft Sentinel provides a visual, interactive map of entities—such as accounts, hosts, and IP addresses—and the relationships that connect them across alerts and incidents. Analysts can expand and pivot through nodes to uncover attack paths, lateral movement, and common associations that are not apparent in raw log lists. This direct exploration of entity relationships is the most effective way to understand the full scope and root cause of an incident, thereby improving investigation efficiency.

The 'AuditIfNotExists' effect is intended to validate the existence of a related resource, such as a diagnostic setting or an endpoint, and it flags resources where that related resource is missing. It does not directly inspect a property of the storage account itself, like whether secure transfer is enabled. To audit or deny a property value, the policy should use the 'Audit' effect (for alerting) or 'Deny' effect (for blocking), with a condition that evaluates that property.

Microsoft Purview retention policies can be assigned to Teams channel and chat messages to preserve data for a defined period such as seven years, protecting it from permanent deletion. eDiscovery tools in the same compliance portal provide search, legal hold, and export capabilities, enabling the organization to locate and produce retained Teams communications when required. Together they satisfy the retention mandate because retention preserves the data and eDiscovery operationalizes access to it.

This is correct because the Conditional Access policy uses Microsoft Entra Identity Protection's real-time sign-in risk score to trigger step-up (for example MFA or restricted session) only when anomalous behavior is detected. Adding an authentication context makes the requirement granular: the risk-based control can be attached to SharePoint sites or files with a specific sensitivity label rather than to every resource. This combines risk assessment with data sensitivity, which is exactly the requirement. It is also the only option that pairs a per-sign-in risk signal with a context-aware session control.

Automation rules are the native orchestration layer in Microsoft Sentinel that run automatically when an incident is created or updated, and they can invoke a playbook as an action. A playbook, built on Azure Logic Apps, can send email, post to Teams, create a ticket, or call any API, making it the proper way to deliver notifications. This is the recommended pattern for automating incident response notifications without custom code.

Customer-managed TDE keys in Azure Key Vault give the organization full control over key lifecycle, including rotation and revocation, and Key Vault logging records every key operation for audit. This directly satisfies the regulatory requirement for controlled, auditable key management without requiring application changes or additional infrastructure.

Windows Security Events via AMA is the correct choice because the Azure Monitor Agent can collect Windows Security log entries from on-premises and Azure Arc-enabled Windows servers. These events include critical authentication-related event IDs like 4624 (successful logon), 4625 (failed logon), and 4768 (Kerberos ticket request), which are essential for detecting lateral movement. The data can be streamed directly to Microsoft Sentinel, allowing analysts to build detections for suspicious logon patterns and pass-the-hash attacks across hybrid identities.

The Safe Links policy is the correct answer because it provides time-of-click URL protection by rewriting links in email messages to point to Microsoft's safety checking service, and it can also scan URLs in Teams and Office apps. When a user clicks a rewritten link, the service checks the URL against real-time threat intelligence and blocks navigation if it is malicious. This ensures that even URLs that look benign at delivery are protected.

Microsoft Sentinel is the only option that functions as a true cloud-native SIEM/SOAR, ingesting security telemetry from across Microsoft Defender products, Azure services, and third-party sources. It provides automation playbooks for incident response, advanced hunting with Kusto Query Language (KQL), built-in threat intelligence connectors, and role-based access control for the SOC. This centralized architecture is essential for aggregating identity, endpoint, and app signals into a single detection and response workflow, meeting the requirement for a security operations center.

Enabling TDE with customer-managed keys in Azure Key Vault is the correct choice because it gives the organization explicit control over the key lifecycle while keeping encryption transparent to the application. You can configure a Key Vault key rotation policy to automatically rotate the TDE protector every 90 days, and Azure SQL Database will automatically use the new key version for new encryption operations without downtime or application changes. This satisfies the rotation requirement with a fully managed, auditable process that is aligned to Azure's native capabilities.

Customizing the anomaly threshold in UEBA is the correct approach because UEBA uses machine learning models that assign anomaly scores to user behaviors, and these models expose threshold and sensitivity settings you can tune. By adjusting the sensitivity, you directly influence the score required to trigger an alert, effectively filtering out low-confidence anomalies that cause false positives while still detecting genuinely suspicious activity. This is the intended, documented method for reducing noise from UEBA-detected behaviors without sacrificing the underlying behavioral analytics capability.

AWS CloudTrail is a valid source because Microsoft Sentinel provides a native data connector that ingests CloudTrail management and data plane logs. By leveraging an S3 bucket and an SQS queue, Sentinel pulls API activity from AWS, allowing security teams to detect misconfigurations, credential abuse, and unauthorized access across AWS accounts.

When the script enumerates Azure resources, it derives the target resource group from the `ResourceGroupName` property of each resource object. This property is accurate for resources inside a resource group, but some resources (e.g., subscription-level policy or role assignments) return a null value, and if the script falls back to a variable or default group, those resources are processed against the wrong resource group. As a result, the lock is created on a scope that does not match the actual resource, leaving the resource unprotected. This is the root cause that also makes the existence-check behavior misleading.

App Protection Policies (MAM) are specifically designed to protect corporate data within applications without requiring the device to be enrolled in device management. They enforce data-loss prevention (DLP) rules like PIN enforcement, data encryption, restrict cut/copy/paste, and prevent saving corporate data to personal stores. In a BYOD scenario, MAM policies apply to managed apps (e.g., Outlook, Word) and ensure that corporate data is contained, regardless of the device's management state, which directly matches the scenario of securing data on personal mobile devices.