Microsoft Cybersecurity Architect (SC-100) — Questions 301–375

Microsoft Authenticator passwordless sign-in is the correct answer because it leverages the same mobile app already widely used for multi-factor authentication, requiring no extra hardware or PKI. The user simply enters their username and then approves a push notification on their phone, sometimes matching a number, while the phone's biometric or PIN validates the physical presence. This provides a phishing-resistant, strong authentication experience that works across Android and iOS, and because it reuses an existing app, user adoption is high and deployment is straightforward.

Session policies in Microsoft Defender for Cloud Apps operate in real time via a reverse proxy to enforce granular conditional access actions on a user's session. They can explicitly block downloads, uploads, and copy/paste based on risk signals such as device posture or user behavior, making them the correct policy type for preventing data exfiltration.

The Defender for Cloud multi-cloud connectors establish the onboarding bridge between Azure and AWS or GCP, synchronizing security configurations, threat indicators, and resource inventory into the unified Azure dashboard. This connector-level integration, which leverages read-only credentials from the foreign cloud, is the mandatory first step because all subsequent security policies, recommendations, and Defender plan coverage depend on the cloud accounts being visible to Azure. Without this connector, Defender for Cloud has no access to the AWS or GCP workloads.

Enabling the Azure Activity data connector in Microsoft Sentinel automatically configures the required diagnostic settings at the subscription level and begins near-real-time streaming of control-plane events into the AzureActivity table within your Sentinel workspace. It is the supported, turnkey method for this integration: the connector handles schema mapping, enrichment, and provides out-of-the-box detection rules, workbooks, and hunting queries. Once enabled, all operations such as resource creation, policy changes, and security alerts are immediately visible in Sentinel.

UEBA in Microsoft Sentinel profiles entities (users, devices, etc.) using historical activity to detect anomalies and enrich alerts with contextual information like risk scores, behavioral deviations, and peer comparisons. Configuring entity behavior settings enables this enrichment to be applied automatically to analytics alerts, providing security analysts with a richer view of the entity's normal vs. anomalous behavior. This directly meets the requirement to enrich alerts with user and device information, unlike static watchlists or detection-only features.

A management group hierarchy provides a scalable governance structure by organizing subscriptions under corporate-level domains, allowing Azure Policy assignments to inherit across all descendant subscriptions and resource groups. Policies, such as enforcing approved VM sizes or location restrictions, can be centrally assigned at the root management group, ensuring consistent compliance. Exemptions offer a controlled mechanism to exclude specific resources from policy evaluation when legitimate exceptions are required, with the ability to set an expiry date. This combination delivers both enforcement and flexibility, making it the correct governance approach.

Analytics rules with alert grouping enabled are the correct mechanism for correlating alerts because Sentinel's incident creation settings allow you to group multiple alerts into one incident based on matching entities, alert titles, or within a specified time window. This grouping reduces alert fatigue by consolidating related detections into a single case for investigation, and it can be configured as either system alert grouping (group all or by entity) or custom grouping with a predefined window.

This is the correct choice: a sensitivity label with auto-labeling for sensitive info types (e.g., a patient ID regex) can be delivered through an auto-labeling policy in Purview, and the label can be configured with encryption via Azure Rights Management. When the label is applied, it encrypts the file, sets viewer/edit permissions, and embeds persistent protection metadata so that the PHI remains protected both at rest and when shared. Because both the classification trigger and the encryption action are integral to the sensitivity label, it uniquely combines automated detection with immediate protection.

A Conditional Access policy can be precisely scoped to the financial applications as the assigned target resources, while using sign-in risk as a condition to trigger MFA. Sign-in risk is calculated in real time by Microsoft Entra ID Protection, and Conditional Access allows it to be set to a threshold such as Low, Medium, or High. When a sign-in to a financial app has a risk level that meets the threshold, MFA is required, directly fulfilling the requirement for risk-based MFA protection on the financial applications without affecting unrelated apps or users.

Microsoft Entra ID Protection detects risky users and sign-ins using machine learning and heuristics, and it integrates with Conditional Access to enforce risk-based policies. It can automatically require password changes or block access when risk is detected, directly meeting the requirement for real-time risk assessment and automated remediation.

Microsoft Sentinel and Microsoft Defender XDR together form a complete monitoring-and-response solution. Sentinel is a cloud-native SIEM that ingests logs from every source, applies analytics rules to detect anomalies, and provides incident management, investigation, and threat hunting, while Microsoft Defender XDR correlates signals across Microsoft Defender for Office 365, Defender for Endpoint, Defender for Identity, and Defender for Cloud Apps. This pairing enables automated response and a single pane of glass for security operations, satisfying the requirement to both monitor and respond to threats across the enterprise.

The policy is configured to target 'All cloud apps', excludes Office 365, and uses the 'Block access' grant control. When a user attempts to access an included application, the policy is evaluated and blocks the sign-in. Since Office 365 is in the exclusion list, the policy is skipped for that application, leaving it unblocked. Therefore, the policy blocks all applications except Office 365.

Report-only mode evaluates the policy and logs what would have happened without enforcing controls, so MFA and device compliance prompts never appear. Because the policy targets all users and all cloud apps, only this mode explains compliant-device users accessing apps unprompted while Microsoft Entra ID records the would-be result.

This is the correct, complete configuration for Microsoft Sentinel. The Identity Protection data connector ingests risk detections and alerts from Azure AD Identity Protection into Sentinel, and the Microsoft Security incident creation rule for Identity Protection is the required analytics rule that automatically generates incidents from those ingested alerts. Without this analytics rule, the alerts remain as raw events with no incident lifecycle, so enabling both together satisfies the requirement to create incidents automatically.

In an ARM template for Azure Storage, the `publicAccess` property of a container is set to 'None', which explicitly blocks any anonymous read requests to the blob data within that container. This configuration ensures that clients must present valid authentication credentials—such as an account key, a shared access signature (SAS), or an Azure AD identity—to access the container's contents. Setting `publicAccess` to 'None' is a critical security control that prevents unauthorized exposure of stored data.

The AWS S3 connector is the correct native Microsoft Sentinel data connector for ingesting AWS CloudTrail logs. It connects to a configured S3 bucket that receives CloudTrail events and optionally uses SQS for near-real-time notifications, then normalizes the JSON records into the AWSCloudTrail table in Log Analytics. This is the standard architectural pattern for centralizing AWS activity monitoring in Sentinel, and it directly satisfies the organization's requirement.

This design centralizes subscription management under a single management group, allowing Azure Policy and Defender for Cloud regulatory compliance dashboards to span the entire environment consistently. The PCI DSS v3.2.1 dashboard continuously assesses all resources, PIM combined with JIT VM access reduces standing privilege and exposed attack surface, and Microsoft Sentinel ingests both cloud and on-premises security data for a unified SOC. It provides an integrated, continuous compliance monitoring and threat detection solution that scales across the organization.

Creating an auto-labeling policy in the Microsoft Purview compliance portal lets you define a rule that scans SharePoint sites, OneDrive accounts, and Exchange for content containing sensitive info types (SITs) for PII, such as U.S. SSN, EU debit card number, or U.S. individual taxpayer identification number. When a match is found, the policy automatically applies the configured sensitivity label and can optionally enforce encryption or a visual marking. This is a rule-based, deterministic detection that works immediately on existing and new content, without user intervention, and is the intended mechanism for automatically classifying PII.

Exchange Online Protection (EOP) provides the always-on baseline filtering for all Exchange Online mailboxes, including spam, bulk mail, malware, and spoof intelligence before a message reaches the user. Microsoft Defender for Office 365 (MDO) layers on top with Safe Attachments, Safe Links, and advanced anti-phishing policy that checks URLs and attachments in real time, plus impersonation and domain-based protection. Together they form the native email security stack, with EOP as the foundation and MDO handling zero-day or social-engineering threats that basic filters miss.

Azure Policy is the correct service for implementing a security baseline because it creates, assigns, and manages rules that audit, deny, or remediate resource properties. It includes built-in policy definitions for the Azure Security Benchmark and other regulatory standards, enabling consistent enforcement across all resources. Policies can be applied to resource groups, subscriptions, and management groups, ensuring that new and existing resources continuously meet security requirements like encryption, network restrictions, and version compliance.

This is correct because a sensitivity label can be configured with auto-labeling rules and encryption so that when an item in SharePoint Online, OneDrive, or Exchange contains a credit card number (detected by the built-in Credit Card Number sensitive information type), the label is applied automatically and the file or email is protected with Azure Rights Management encryption. The auto-labeling policy can run as a simulation first to evaluate matches, then be enforced, ensuring both classification and protection happen without user action. This architecture directly satisfies a requirement for automatic classification and encryption.

DataPlaneRequests is the diagnostic log that records every data plane request against an Azure Cosmos DB account, regardless of the API in use (SQL, MongoDB, Cassandra, Gremlin, Table). Each entry includes the operation type (e.g., create, read, upsert, delete, query), resource URI, partition key range, current status code, request charge, client IP, and authentication token type. This comprehensive coverage of all CRUD and other data operations makes it the correct source for auditing and forensic analysis of data plane activity.

Istio service mesh runs Envoy sidecar proxies next to each microservice, giving it the ability to issue SPIFFE-based identities and automatically encrypt and authenticate all service-to-service traffic with mutual TLS. It also provides authorization policies and traffic management, making it the correct solution for internal microservice mTLS on Azure Kubernetes Service or virtual machines. This directly addresses the need for workload-level identity and encryption between microservices.

The Windows Security event log via the Azure Monitor Agent (AMA) is the standard and authoritative source for logon audit events, specifically Event ID 4625, which logs every failed account logon attempt. For hybrid machines, configuring a data collection rule (DCR) to forward Security events to Microsoft Sentinel enables detection of password-spraying and brute-force attempts. AMA is the current agent replacing the Log Analytics agent and preserves the necessary event details, such as source IP and target account, for high-fidelity analytics.

Enabling SQL Database auditing satisfies the secure-configuration requirement by recording all database events to a storage, Log Analytics or Event Hub destination, giving the detective evidence trail that Azure Policy's Auditing effect enforces at scale across every server and database in scope.

Enforcing HTTPS on both apps meets requirement one, Microsoft Entra ID authentication on the web app restricts access by corporate identity, and a system-assigned managed identity lets the API reach Azure SQL Database without stored secrets.

Intune compliance policies assess a device's security posture—such as jailbreak status, OS version, encryption, and threat level from Defender for Endpoint—and generate a compliant/non-compliant state that is stored in Azure AD. Conditional Access policies then consume that state at sign-in, using a 'Require device to be marked compliant' grant control to block or allow access to email and other corporate resources. This is the definitive mechanism because it combines continuous health evaluation with identity-driven enforcement, and it works with both Android and iOS device-specific checks like the SafetyNet attestation or Apple's device compliance.

Enforcing TLS 1.2 ensures encrypted connections. Azure Defender for SQL (part of Microsoft Defender for Cloud) provides vulnerability assessment and advanced threat protection, including detection of SQL injection attempts. Configuring auditing to Azure Monitor logs enables monitoring and auditing of database activities. This combination addresses all three requirements: encryption, SQL injection protection, and auditing.

This option is correct because it leverages the built-in, integrated protections of Microsoft 365 Business Premium. Microsoft Defender for Office 365 filters malicious attachments and link-time detonation in Exchange Online, while Defender for Business provides endpoint detection and response plus controlled folder access that blocks unauthorized processes from modifying user files. Phishing education reduces initial compromise, and OneDrive Files Restore enables users to roll back an entire library to a known-good state within 30 days without heavy IT administration.

This is the correct approach because Azure Policy is the native, continuous compliance service for resource-level configurations. By creating custom policy definitions for allowed locations, NSG rules, and storage HTTPS and assigning them at the root management group, the policies inherit to all child subscriptions and resource groups, providing a single, central governance baseline. Enabling the DeployIfNotExists effect makes Azure Policy automatically deploy the required configuration (e.g., a compliant NSG or secure storage setting) whenever a non-compliant resource is created or updated, and remediation tasks then correct pre-existing non-compliant resources, closing the compliance gap without manual intervention.

Input validation is a secure-coding control that rejects or sanitizes any user-supplied data that does not conform to expected formats, types, or lengths before the application processes it. By applying allowlist patterns and output encoding, it prevents malicious payloads from being interpreted as executable code, directly thwarting SQL injection, command injection, and stored/reflected XSS. It must be applied both on the client for UX and, critically, on the server as the authoritative enforcement point, and it is the first line of defense against the OWASP Top 10.

The Microsoft Entra ID connector (formerly Azure AD) is the correct choice because it directly ingests SigninLogs and AuditLogs from Entra ID into Sentinel. These tables contain authentication attempts, conditional access results, and user and group administrative changes, which are the exact identity telemetry the customer needs. This connector enables you to build analytics rules for sign-in anomalies, MFA failures, and suspicious audit activity.

The user risk condition in Conditional Access depends on Azure AD Identity Protection's risk signals. Without Azure AD Premium P2 licenses, or if the Identity Protection risk policy is not configured, the user risk condition has no data to evaluate, so the condition is never satisfied and the policy never applies. Consequently, even though the policy appears active, it will not enforce its access controls because risk evaluation is effectively skipped.

This query detects brute-force attacks by identifying patterns of repeated failed logon attempts (EventID 4625) originating from the same source IP address or targeting a single account. In a brute-force attack, an attacker systematically tries many username/password combinations against Windows servers, generating a high volume of 4625 events with a common Source Network Address. The query likely aggregates failed logon counts and thresholds, making it directly suitable for surfacing brute-force activity.

Transparent Data Encryption (TDE) encrypts entire database files, backups, and transaction logs at rest using a database encryption key, protecting data at the storage layer. Always Encrypted goes further by encrypting sensitive columns with client-side keys so that database administrators and cloud operators see only ciphertext, ensuring data remains confidential even during queries. Azure SQL Auditing captures a trace of database events and queries, enabling compliance monitoring and forensic analysis of access to sensitive data. Together, these three technologies deliver encryption at rest, column-level encryption with key separation, and a clear audit trail, fully addressing typical enterprise data protection and compliance requirements.

Private endpoints for Azure SQL Database and Azure Storage assign each resource a private IP address from your virtual network, ensuring that all traffic to these PaaS services traverses the Microsoft backbone network and never the public internet. This provides strong network-level isolation because the service endpoint is only reachable from your VNet, and you can disable public access entirely, eliminating exposure to internet-based attacks. Private endpoints also support Azure Private Link, which integrates with network security groups, route tables, and on-premises connectivity via VPN or ExpressRoute. Unlike service endpoints, private endpoints give you granular control over which specific resource instances can be accessed, not just the service as a whole.

Microsoft Entra Connect is the on-premises hybrid identity synchronization engine that installs on a server and replicates directory objects (users, groups, contacts, and devices) from your local Active Directory to Microsoft Entra ID. It is the correct answer because its primary purpose is to establish a single source of identity across on-premises and cloud directories, and it also configures the chosen authentication method (password hash sync, pass-through authentication, or AD FS federation). Without this tool, you cannot maintain synchronized identities for hybrid scenarios.

A custom sensitive info type is the right mechanism because it lets you define a regular expression to match the credit card number format, optionally with the Luhn checksum validation, plus a keyword list (e.g., 'VISA', 'MasterCard', 'card number') to raise confidence and reduce false positives. Purview uses these custom SITs in DLP policies, auto-labeling, and retention label conditions. This directly gives you a detectable classification without depending on built-in types.

Azure Bastion is a fully PaaS-based service that provides secure RDP/SSH access to Azure VMs over TLS, eliminating the need for any public IP addresses on the VMs themselves. It includes RBAC integration, Azure AD authentication, and hybrid AAD join support, while also allowing you to restrict inbound traffic through NSG rules to only the Bastion subnet. This reduces the attack surface for management ports by never exposing them to the internet and supports auditing via Azure Monitor.

Microsoft Defender XDR is a core security solution because it correlates signals across endpoints, email, identities, and cloud apps, enabling extended detection and response. In a Zero Trust architecture, it serves as the enforcement and detection plane that consumes identity and endpoint telemetry. Integrating it with Entra ID lets suspicious identity behavior trigger automated response actions such as blocking a sign-in.

An auto-labeling policy for sensitivity labels with encryption is correct because it uses sensitive info types or trainable classifiers to scan content and automatically apply a label that triggers Microsoft 365 encryption (AES-256) and rights management. This label persists with the file or email and enforces policies such as view-only, Do Not Forward, watermarking, and conditional access, regardless of where the data is stored or shared. Because the encryption is tied to the label and managed by Azure AD RMS, the protection is permanent and follows the data even when it leaves the tenant or is copied to other applications, meeting the core requirement to protect sensitive data automatically.

PIM provides just-in-time, time-bound, and approval-based activation of privileged roles across Azure AD, Azure resources, and other Microsoft services. It eliminates permanent standing admin access by requiring users to request activation for a limited window, with MFA and policy-based approvals. In an Entra ID governance deployment, PIM directly governs the assignment and activation of privileged roles, making it the correct answer for the scenario.

The Amazon Web Services S3 connector is the built-in Microsoft Sentinel connector for AWS, ingesting CloudTrail management events (and optionally data events) via logs stored in an S3 bucket. It uses an SQS queue to notify Sentinel of new log files, and an Azure Function runs to pull them into the Log Analytics workspace. This is the standard, supported method for continuous AWS log ingestion, making it the correct option.

Assigning a policy with the 'deny' effect at subscription scope makes Azure Resource Manager evaluate every create/update operation against the policy rule before provisioning. If a resource is non-compliant, the platform rejects the request with a 403 or similar error, so no infrastructure is ever deployed that violates governance. Because this happens in the control plane, it works uniformly for portal, CLI, PowerShell, templates, and DevOps pipelines, closing the gap that manual or network-based controls leave open.

The Microsoft Defender XDR incident integration is the correct answer because it connects Microsoft 365 Defender (covering endpoints, identities, email, and cloud apps) directly to Sentinel, pulling in pre-correlated incidents rather than raw alerts. This integration provides a single queue for security operations, enables bidirectional incident synchronization (status changes propagate both ways), and allows analysts to leverage Sentinel's SOAR actions across Defender XDR incidents. Without this integration, defenders would need to juggle multiple portals, losing the unified visibility that the question requires.

Network Security Groups are the fundamental Azure service for filtering traffic between subnets in the same virtual network. They are stateful and contain inbound and outbound security rules that evaluate source/destination IP, port, and protocol, allowing you to permit only required traffic between tiers (e.g., web to app on 443). By default, all VNet traffic is allowed, so explicit NSG rules are required to enforce least-privilege segmentation.

Azure Policy evaluates storage accounts against a built-in or custom definition and enforces the 'Secure transfer required' setting, remediating non-compliant resources at scale. This satisfies the stem's requirement to ensure the setting is enabled across all storage accounts.

This combination forms a complete Conditional Access pipeline. Intune reports device compliance state—including patching, encryption, and jailbreak status—to Entra ID, which evaluates that signal alongside user and location at sign-in. Defender for Cloud Apps then enforces session-level and app-level policies, such as blocking downloads from a risky app or requiring additional controls. Together they deliver end-to-end Zero Trust for cloud resources.

UEBA in Microsoft Sentinel profiles entities such as users, devices, and applications by establishing a baseline of their typical activities—like login times, geo-locations, accessed resources, and peer-group interactions. It then assigns an anomaly score to each deviation from that baseline, with high scores indicating potentially malicious or risky behavior. This method detects threats that may be unrecognized by signature-based tools because it focuses on behavioral change rather than known attack patterns, enabling identification of compromised entities or insider threats.

Reviewing NSGs and firewall rules is correct because VMs require outbound connectivity to Microsoft endpoints for both Windows Update and Microsoft Defender for Endpoint cloud services. If egress is blocked, update scans fail, definition updates cannot download, and Defender for Endpoint sensors cannot upload machine telemetry or receive policy. The fix should ensure NSG rules and any network virtual appliance or firewall allow traffic to the service tags (e.g., WindowsUpdate, AzureFrontDoor, and Defender for Endpoint URLs/IPs). This directly addresses the root cause rather than layering management, policy, or identity tools.

SOAR playbooks in Microsoft Sentinel are Azure Logic Apps–based workflows that automate response and remediation actions when triggered by an incident, alert, or automation rule. They can run actions like isolating a compromised VM, blocking an IP, or sending notifications, and they integrate with external tools like Microsoft Defender or third-party SOC platforms. Playbooks are the correct option because they provide active remediation, not just detection or visualization.

Azure AD Connect's default delta synchronization runs every 30 minutes, which determines how soon on-premises directory changes appear in Azure AD. By configuring the synchronization interval to a shorter period, you reduce the latency of object and attribute updates. This is the appropriate action to speed up propagation of directory changes, because the interval directly controls the replication rhythm. Since the step is to take for faster synchronization, this choice satisfies the scenario.

Contained database users mapped to Azure AD identities are the correct mechanism for authenticating users at the database scope. These users are defined entirely inside the database, and Azure SQL validates their Azure AD bearer token during login, so no server-level login is needed. This approach supports least privilege because permissions are scoped to the database, and you can map the user to an individual Azure AD user or a group using CREATE USER ... FROM EXTERNAL PROVIDER.

Conditional Access policies in Microsoft Entra ID act on real-time signals such as user risk, device compliance state, sign-in location, and session risk to allow access, block it, or trigger step-up authentication. This is a direct implementation of 'verify explicitly' because every access attempt is evaluated against multiple context-aware criteria before a token is issued or access is granted. The same user can be permitted on a compliant managed device but blocked or challenged when the same request originates from an unmanaged personal device, embodying never-trust-always-verify.

TDE encrypts the entire Azure SQL database, including backups and transaction logs, transparently to applications, satisfying the at-rest encryption requirement without schema changes. DDM complements this by obfuscating sensitive columns at query runtime for non-privileged users, preventing accidental exposure of sensitive data over the network or in application results. Together they provide encryption at rest plus a display-level control, covering both storage and query-time confidentiality.

An analytics rule in Microsoft Sentinel is the detection engine that runs a scheduled or near-real-time KQL query against the workspace. When the query returns results that match the rule's condition (for example, any logs showing access from the suspect IP), it triggers an alert and automatically creates an incident with associated entities, severity, and tactics. This is the only option that performs both detection and incident creation, making it the correct way to be alerted to such access.

In Microsoft Entra ID Protection, the user risk level is an aggregated probability that an account has been compromised, calculated from multiple risk detections over time. When the user risk level is rated 'high', the service raises a user risk alert, which is exactly what this exhibit displays. The alert metadata shows the user risk as 'high', so the condition that triggered this alert is the high user risk classification, not any other factor like sign-in risk or a specific leaked credential event.

Verifying explicitly is the core zero trust principle: every access request is authenticated and authorized based on all available data points, including user identity, device posture, location, data classification, and anomaly signals. This eliminates implicit trust and ensures that access decisions are made for each session and each request, even for previously authenticated entities. It is the primary principle that distinguishes zero trust from traditional perimeter models.

In Azure, NSG rules are evaluated in ascending priority order, where smaller numbers are processed first and the first matching rule determines the outcome. If DenyAll has a numerically lower priority (e.g., 100) than AllowHTTP (e.g., 200), then incoming TCP port 80 HTTP traffic matches DenyAll first, and since its action is Deny, the packet is dropped before AllowHTTP is ever considered. This explicit numeric precedence is the direct cause of the HTTP failure, making the higher priority of DenyAll the definitive reason.

Microsoft Defender for Endpoint is the correct choice because it is an endpoint detection and response (EDR) solution that continuously monitors devices for malicious activity, triggers automated investigation, and executes remediation playbooks. Its automated response capabilities include quarantining infected or suspicious files, killing malicious processes, and isolating entire devices from the network—exactly the kind of 'auto' response the organization requires. As the endpoint component of Microsoft Defender XDR, it provides the necessary telemetry and action primitives for autonomous threat containment.

This solution combines real-time risk assessment from Microsoft Entra ID Protection with adaptive Conditional Access policies, allowing sign-in risk to trigger MFA, block, or session restrictions dynamically. Session controls from Microsoft Defender for Cloud Apps enable granular cloud app session monitoring and policy enforcement, such as blocking download of sensitive files based on user risk. Blocking legacy authentication explicitly via a Conditional Access policy on client apps 'Exchange ActiveSync' and 'Other clients' is the documented method to prevent credential replay attacks. Finally, integrating Microsoft Sentinel with Defender XDR centralizes alerts from across the identity, endpoint, and cloud app domains, enabling advanced hunting and a unified incident response workflow.

Anti-phishing policies in Microsoft Defender for Office 365 contain the 'Phishing email threshold' setting, which adjusts the sensitivity of the machine-learning models that detect phishing attempts. These policies also include features like impersonation protection, mailbox intelligence, and spoof intelligence, all relevant to phishing defense. This is the correct policy selection because it directly modifies the advanced threshold that controls how many phishing candidates are flagged.

An auto-labeling policy in Microsoft Purview can be configured to automatically apply a sensitivity label to documents stored in SharePoint Online. You select the sensitivity label, choose the 'SharePoint Online' location, specify the sites, and define conditions based on sensitive info types or trainable classifiers. After testing, the policy can be set to enforce automatic labeling, which satisfies the requirement to classify the documents.

Least privilege access is a cornerstone of Zero Trust because it directly reduces the potential blast radius of any compromised identity or device. Access is granted strictly on a need-to-know basis, often enforced with just-in-time (JIT) elevation and just-enough-access (JEA) scoping. This applies not only to human users but also to workloads, services, and APIs via fine-grained conditional access policies and microsegmentation. Implementing least privilege ensures that a single credential theft does not automatically grant access to downstream systems.

In Microsoft Defender for Cloud, each security recommendation—including 'Secure transfer to storage accounts should be enabled'—is backed by an Azure Policy definition. Implementing this recommendation executes a remediation task that applies the policy effect (typically 'Audit' or 'DeployIfNotExists') to the identified storage accounts, setting the 'supportsHttpsTrafficOnly' property to true. This is the only option that directly enforces the required configuration, as it modifies the resource to meet the policy's compliance criteria, unlike assessment-only features.

The Microsoft Sentinel data connector for Azure Activity is the authoritative, supported integration for ingesting control-plane events into the Sentinel workspace. This connector provisions the necessary data collector and maps the stream to the `AzureActivity` table, enabling analytics, hunting, and alerting. It appears in the Data connectors blade and is the standard first step when onboarding tenant-level logs.

In Microsoft Purview, an auto-labeling policy applies retention labels automatically to SharePoint Online documents based on sensitive information types, such as PII, using content pattern detection. This satisfies the stem’s constraint of automatic application without user intervention, unlike manual or default label policies, which require user action or static inheritance.

The correct mechanism for grouping related alerts into a single incident is configuring an analytics rule with alert grouping enabled. When enabled, the rule's alert grouping settings (such as grouping by entities or within a defined time window) cause multiple qualifying alerts to be automatically combined into one incident, rather than each alert creating a separate incident. This reduces alert noise and gives security analysts a correlated view of a potential attack chain.

Microsoft Intune is a unified endpoint management solution that enforces zero trust by ensuring devices are compliant and healthy before they access resources. It does this through device compliance policies (e.g., required OS versions, disk encryption, and jailbreak detection) that integrate with Entra ID Conditional Access, blocking or limiting access for non-compliant devices.

A system-assigned managed identity lets App Service obtain Microsoft Entra ID tokens without any secret in code or configuration, and the underlying credential is rotated by the platform. Azure Functions can validate the token and restrict callers to the portal's identity, satisfying both the no-secret and auto-rotation requirements.

Microsoft Entra Privileged Identity Management (PIM) is the correct service for just-in-time privileged access. PIM allows an admin to configure roles so that users become eligible, and then activate the role for a specified time window, optionally requiring multi-approval. It also provides auditing, alerts, and access reviews to govern privilege use, directly addressing the need for approval workflows and time-bound activation.

Endpoint security policy for disk encryption is the correct approach because it consolidates all BitLocker controls — encryption method, XTS-AES cipher strength, TPM protector usage, and recovery key escrow to Entra ID — into a single, purpose-built policy type. Unlike compliance checks or ADMX templates, it actively configures BitLocker and can enforce encryption silently on target Windows devices. It aligns directly with Microsoft's security baseline guidance and provides clear status reporting in the security center.

Conditional Access policies requiring MFA for privileged roles are a cornerstone identity protection control. These policies enforce an additional authentication factor at sign-in for users assigned to highly privileged directory roles, such as Global Administrator or Application Administrator, irrespective of location or device state. This directly thwarts stolen-password and password-spraying attacks, because an attacker lacking the second factor cannot gain access. For robust defense, such policies should be paired with device compliance checks and session controls to further harden privileged access.

This is correct. The Azure Policy assignment uses the 'audit' effect to evaluate whether SQL databases have Transparent Data Encryption (TDE) enabled. If a database does not have TDE enabled, the policy marks that resource as non-compliant in the Azure Policy compliance dashboard and potentially integrates with Azure Monitor for alerts and reports. The 'audit' effect only evaluates and reports—it does not automatically remediate the non-compliant database, but it does accomplish the goal of identifying and flagging resources that fail to meet the intent of the policy. This matches the behavior shown in the exhibit where the policy is configured with an audit effect and assigned to a resource group.

The query first filters to High-severity alerts (likely via where Severity == 'High'), then uses summarize to count occurrences per alert name, and orders the results by count descending. This produces a ranked list of high-severity alert types based on frequency, which directly identifies the most common high-severity alerts over the specified time range. The 7-day window is established by a time filter in the where clause, aligning with the question's scenario.