Microsoft Cybersecurity Architect (SC-100) — Questions 526–600

The native way to extend Defender for Cloud to AWS and GCP is the multicloud connectors feature: for AWS you create a CloudFormation stack that provisions a role with the required read permissions, and for GCP you create a service account and project binding. Once connected, Defender for Cloud automatically aggregates security recommendations, regulatory compliance scores (CIS, PCI DSS, etc.), and workload protection plans across Azure, AWS, and GCP in the same portal blade. This is the intended first-class mechanism and does not require Azure Arc or Sentinel.

A Windows 10 device restriction profile contains an 'Apps' category with a setting named 'Block installing apps from sources other than Microsoft Store' (the Store-only installation toggle). Setting this to 'Block' enforces the Windows AppRuntime policy that allows or disallows apps based on trusted source. The Intune profile also covers related switches like 'Block all apps from the Microsoft Store,' giving granular control. This is the native, purpose-built mechanism in Microsoft Intune to prevent untrusted app installation.

The Azure SQL Database connector ingests diagnostic telemetry such as SQLInsights and QueryStoreRuntimeStatistics, which include the client IP address for every connection. A custom scheduled query rule can run KQL to map these IPs to geographic locations (using the GeoIP enrichment or a watchlist) and alert when a connection originates from a country that is abnormal for your environment. This directly captures data-plane connection attempts to Azure SQL, so it is the correct pairing of source and detection logic.

PIM is the Entra ID service purpose-built for just-in-time, time-bound privileged role activation. Administrators are made eligible for roles, and when they need access they activate for a requested duration—optionally with MFA, business justification, and an approval workflow—after which the role expires automatically. This directly replaces permanent 'standing' admin access with auditable, as-needed elevation.

Web Application Firewall (WAF) on Azure Front Door is the correct choice because it operates at the application layer (Layer 7) and uses managed rule sets (e.g., OWASP Core Rule Set) to inspect incoming HTTP/HTTPS requests for malicious payloads like SQL injection and cross-site scripting. By enforcing these rules at the edge, it blocks attacks before they reach the origin web server. Unlike network-level controls, WAF deeply inspects request bodies and headers, directly mitigating the vulnerability described in the question.

'Block with override' in Purview DLP halts the sharing of credit card numbers by default, but when 'Business justification' is enabled, users can bypass the block if they provide a reason. This balances security with operational continuity, and because overrides are audited, it maintains accountability while preventing accidental data exposure.

The policy explicitly prohibits the creation of network interfaces that are configured with a public IP, and since a virtual machine must have at least one NIC to boot, any VM deployment that attempts to attach a public IP to its primary NIC will be blocked. The deny effect causes the entire deployment request to fail with a conflict or forbidden error, preventing both the NIC and the VM from being created. This is a hard failure, not a soft warning, because the policy's effect is Deny, not Audit or Modify.

Azure WAF on Front Door or Application Gateway is the correct solution because it inspects incoming HTTP(S) requests at Layer 7, specifically filtering for SQL injection, cross-site scripting (XSS), and other OWASP Top 10 attack patterns before they reach the App Service backend. Using managed rule sets such as the OWASP CRS, it provides continuous, low-maintenance adaptability to new attack signatures. This directly addresses the described application vulnerabilities, unlike network- or secret-management controls.

Azure Web Application Firewall on Application Gateway inspects HTTP traffic at the edge and applies managed rule sets that block SQL injection and cross-site scripting. Terminating at the gateway gives the centralised, network-edge protection the scenario requires.

The query aggregates failed sign-in events, grouping by account and source IP address, then filters for counts exceeding a threshold. This surfaces accounts experiencing multiple failed logon attempts from a single IP, indicating possible brute-force or password-spray activity.

Setting `denyEncryptionScopeOverride` to `true` on a container blocks any client from supplying an encryption scope different from the container's default scope on a per-blob request. As a result, every blob uploaded to this container is encrypted exactly with the default encryption scope, which administrators centrally define and manage. This is essential for compliance scenarios where data must always be encrypted with an approved key or key management policy.

Cross-domain correlation of alerts is a core benefit of Microsoft Defender XDR because it ingests signals from Microsoft Defender for Endpoint, Identity, Office 365, and Cloud Apps, and fuses them into a unified incident. This correlation enables security teams to see the full attack chain—such as a phishing email leading to credential theft and lateral movement—rather than investigating disjointed alerts. This is exactly the value that differentiates XDR from single-vector security tools.

Azure Key Vault is the correct service for secrets because it offers centralized management, access policies, rotation, and auditing; linking Azure DevOps Variable Groups to Key Vault retrieves secrets securely at pipeline runtime without exposing them in logs. Enabling Microsoft Defender for Containers on AKS automatically scans container images in ACR for vulnerabilities and provides runtime threat detection. Azure Policy with Gatekeeper (the AKS admission controller) enforces that only images from approved registries are deployed, providing governance and preventing unauthorized or malicious image usage.

Automation rules in Microsoft Sentinel continuously run on incident creation, updating, or closing events and can invoke an Azure Logic Apps playbook when an incident is triggered. The playbook can use the Azure Firewall connector to add a deny rule for the specific IP, directly modifying the firewall's network rule collection to stop the attack at the network layer. This combines SIEM threat detection with SOAR-driven response, enabling real-time, automated IP blocking without manual intervention and with full audit trail.

OAuth app policies in Defender for Cloud Apps are the correct choice because they specifically enable automated governance for third-party applications that have been granted consent in Azure AD. These policies can continuously monitor the app's activity, user involvement, and permissions, and automatically revoke access or apply a quarantine action when the app is deemed risky or exceeds a preset threshold. Unlike manual remediation, these policies execute the revocation directly on the OAuth application, removing its granted permissions without requiring a user to revoke consent manually.

Deny all network traffic by default is correct because the storage account template sets the networkAcls.defaultAction property to Deny. With this configuration, any request that does not match an explicitly permitted rule (such as a service endpoint or virtual network rule) is blocked at the network layer. This enforces a strict zero-trust baseline: all inbound traffic is denied unless an exception is explicitly defined, making it the primary network hardening control in the template.

This is the correct solution because it layers the three essential controls: Defender for Office 365 Safe Links and Safe Attachments protect users from sophisticated phishing payloads in real time, while a Microsoft Purview DLP policy detects and blocks external sharing of sensitive data at the point of exfiltration. The Conditional Access policy requiring MFA and device compliance ties identity and device trust together, ensuring that only healthy, authenticated devices can access corporate resources. Together these address email security, data exfiltration prevention, strong authentication for all users, and device health—the four core requirements.

The storage account is compliant because encryption is configured with customer-managed keys from Key Vault, as shown by 'keySource': 'Microsoft.Keyvault', and the network rule 'defaultAction': 'Deny' is overridden only for a specific virtualNetworkResourceGroup and subnet. This combination ensures data at rest is encrypted with controlled keys and access is restricted to a designated virtual network, meeting policy requirements.

A system-assigned managed identity creates an Azure Active Directory-backed identity directly tied to the application resource, so no credentials are stored in code or configuration. Granting only the Key Vault Secrets User role on the key vault enables least-privilege read access to secrets, and Azure automatically rotates the backing principal's credentials, which eliminates secret management and reduces the risk of credential leakage.

Zero Trust rejects implicit trust from network location; every request is authenticated and authorised against policy using identity, device and context signals. Assuming breach drives least-privilege access and continuous verification, which is the guiding principle the strategy requires.

AppLocker is the correct answer because it enforces application control by creating rules that allow or deny executables, scripts, installers, and DLLs based on file attributes like publisher, product name, file hash, or path. These rules are applied by the AppLocker engine at process initiation, so unauthorized applications are blocked from running. Intune can deploy AppLocker policies via endpoint security and configuration settings, making it a valid application control solution for managed Windows 10 devices.

Azure Key Vault provides centralized, hardware-backed secret storage with granular access policies and full audit logging. Pairing it with a managed identity means the application authenticates to Azure AD using a workload identity token, never needing a secret or connection string in code or configuration. This enables seamless secret rotation and supports the zero-standing-credentials principle, making it the only option that meets cloud-native security best practices.

Cloud Security Posture Management (CSPM) is a foundational capability of Microsoft Defender for Cloud that continually scans resource configurations across Azure, AWS, and GCP, comparing them against standards like the Azure Security Benchmark. It generates a Secure Score, highlights misconfigurations, and offers step-by-step remediation, enabling security teams to prevent vulnerabilities before exploitation. Because it directly targets the cloud control plane and configuration drift, CSPM is the best practice for continuous security assessment.

An auto-labeling policy for retention labels is the correct solution because it natively supports automatic application of retention labels to content that matches sensitive info types, such as credit card numbers. These policies run across a tenant and can target SharePoint sites, OneDrive accounts, and Exchange mailboxes, evaluating content against built-in sensitive information types and applying the designated retention label. This approach directly aligns with the requirement to protect sensitive data while ensuring it is retained appropriately. Auto-labeling for retention labels is distinct from sensitivity-label auto-labeling, as it specifically governs data lifecycle rather than classification.

Managed identity eliminates long-lived service principal credentials by providing an Azure AD-backed identity automatically rotated, which AKS uses to authenticate to Key Vault. The Secrets Store CSI driver mounts selected Key Vault items directly into pods as ephemeral volumes, so secret material never persists in etcd and supports rotation without pod restarts. Deploying AKS as a private cluster ensures the Kubernetes API server receives only private IP addresses, preventing exposure to the public internet. Enabling diagnostic settings on Key Vault streams audit event logs to Log Analytics, giving the security operations team a centralized, queryable trail of access and modifications.

Retention labels and retention policies in Microsoft Purview can keep Exchange mailbox content for a defined period and preserve it when a user leaves by converting the mailbox to an inactive mailbox if the hold is applied. Retention also blocks permanent deletion of items that are still within the retention period, which satisfies the preservation requirement across the seven-year window.

Data Loss Prevention policies for Copilot are specifically designed to detect sensitive information types—such as credit card numbers or personally identifiable information—within Copilot prompts and responses, and can take automatic actions like blocking or warning the user. These policies integrate with the Microsoft Purview console and apply contextual constraints based on the data being processed, making them a content-aware control that mitigates exposure at the point of interaction. Unlike identity or classification-only controls, DLP actively prevents exfiltration by interrupting the prompt/response flow when a violation is matched.

Windows Security Event ID 4624 records every successful logon, including the logon type (Type 3 for network logons), the authentication package, and the source workstation/IP address. Pass-the-Hash attacks commonly result in a Type 3 logon using NTLM, where the logon process and elevated privileges stand out when correlated with other anomalies. This event is the definitive source for detecting credential reuse because it reveals the method by which the account accessed the target machine, making it the correct telemetry for Pass-the-Hash monitoring.

Using Microsoft Entra ID with Conditional Access policies that require compliant devices evaluates the device’s compliance state as reported by Intune at sign-in time, combining identity signals with device health to grant or deny access. This approach enforces Zero Trust principles by allowing only managed, compliance-checked devices to reach both cloud and on-premises applications, while also providing seamless SSO through Entra ID. Because it blocks non-compliant devices before session establishment, it directly satisfies the remote access security requirement more effectively than a VPN or application proxy alone.

A DLP policy scoped to Exchange Online inspects email traffic and applies sensitive information type matching for credit card numbers, blocking sharing at the transport layer. This directly satisfies the stem's requirement to prevent email exfiltration, since Exchange Online is the workload governing mail flow within Microsoft Purview.

Continuous Access Evaluation (CAE) is the correct mechanism because it forces Microsoft Entra ID to re-evaluate Conditional Access policies when critical events occur, such as user account disablement, password reset, or session revocation, rather than waiting for token expiration. It uses a multi-party token that carries a time-limited claim, and resource providers listen for cancellation signals, allowing access to be cut off within minutes. This is true continuous verification because both the token lifetime is shortened and the risk or compliance state is rechecked proactively.

This is the correct reason. The Azure Policy definition likely contains a rule that denies or audits storage accounts where SupportsHttpsTrafficOnly is false. When secure transfer is disabled, the storage account accepts HTTP traffic, so the property is set to false and the policy marks the resource as non-compliant. If the policy effect is Deny, the storage account creation would even be blocked at deployment time. Therefore, the storage account was created with the 'Secure transfer required' setting disabled.

Conditional Access is the correct enforcement point because it lets you build policies that require MFA based on any combination of signals—user, group, device compliance, location, application, or session risk—from the Entra Identity Protection feed and other sources. A policy such as 'Require MFA for all users' directly enforces a second factor on every authentication attempt, and can also apply step-up auth or session controls conditionally. This policy-driven control is the core of a zero trust architecture, ensuring authentication is continuously verified per access request.

A custom sensitive information type allows you to define a pattern using regular expressions, keywords, and validity checks to match specific sensitive data (e.g., employee IDs). When this type is referenced in an auto-labeling policy, Purview scans content and applies the configured sensitivity label on matches. It is the mechanism that identifies the content pattern, making it the correct choice for classification and labeling based on custom-defined data.

App connectors in Microsoft Defender for Cloud Apps leverage the cloud provider's native APIs (e.g., Box and Dropbox REST APIs) to pull metadata, activities, and file content for continuous, near-real-time monitoring. This allows you to enforce data loss prevention policies, detect user anomalies, and apply governance actions without relying on traffic interception. This is the correct method because it integrates directly with the apps you want to monitor and control, giving you full visibility and control over sanctioned usage.

Microsoft Defender for Office 365 is one of the core workload products natively integrated into Microsoft Defender XDR. It protects email and collaboration services such as Exchange Online, SharePoint, Teams, and OneDrive for Business by detecting phishing, malware, malicious links, and business email compromise. Its telemetry is shared with the XDR unified incident engine, enabling cross-domain correlation with endpoint and identity signals for automated investigation and response.

Conditional Access policies in Microsoft Entra ID are the enforcement engine that uses signals such as device compliance, user risk, and location to allow or block access to cloud resources. When paired with Intune compliance policies, a Conditional Access policy can require that a device be marked as compliant, thereby blocking access if the device is not compliant. This makes Conditional Access the correct mechanism for enforcing access based on compliance, rather than merely defining compliance.

Azure AD Privileged Identity Management (PIM) is the specific capability designed to enforce just-in-time (JIT) and time-bound activation of privileged roles, directly implementing least-privilege access by requiring step-up authentication, approval workflows, and justifications before elevation. PIM additionally issues scoped, temporary role assignments and provides audit logs and access reviews, making it the targeted answer for minimizing standing administrative privileges in a zero-trust architecture.

Hardcoding the administrator password as a plaintext string in the Bicep template is a critical security flaw. Anyone with read access to the template or the source control repository can extract the credential, and the secret is also exposed in deployment history. This violates Microsoft's recommendation that secrets must be stored in Azure Key Vault and referenced via the `keyVault` reference or `getSecret` function, or accepted as a secure parameter at deployment time.

Security policies and initiatives in Microsoft Defender for Cloud are built on Azure Policy and include regulatory compliance frameworks like the Microsoft cloud security benchmark. These initiatives contain policy definitions that can audit, deny, or deploy settings such as 'Secure transfer to storage accounts should be enabled' (supportsHttpsTrafficOnly). When assigned to a subscription, Defender for Cloud continuously evaluates storage account compliance and can enforce secure transfer automatically via a DeployIfNotExists effect, directly addressing the requirement to enable secure transfer.

Microsoft Entra Privileged Identity Management (PIM) allows you to configure role settings that require approval for activation and set a maximum activation duration. You can specify approvers, require justification, and limit activation to a specific number of hours. This directly meets the requirements for just-in-time privileged access with approval workflow and time-bound activation.

Data is the ultimate security target and is protected at rest, in transit, and in use through classification, encryption, and rights management. Zero Trust enforces granular access policies based on data sensitivity, with DLP and DRM ensuring protection even after access is granted. Without data protection, all other components become moot, making data one of the central pillars of the model.

SharePoint Online is the primary collaborative document repository in Microsoft 365 where organizations store most sensitive files, including contracts, policies, and confidential records. Microsoft Purview natively indexes SharePoint Online sites and document libraries, allowing sensitivity labels, trainable classifiers, and data loss prevention (DLP) policies to identify and protect sensitive content. Because SharePoint is central to M365 file storage and classification, it is the correct source to include in a Purview data classification design.

Sensitivity labels in Microsoft Purview Information Protection apply persistent, tamper-proof metadata to content—such as confidentiality, encryption, and visual markings—which Copilot for Microsoft 365 explicitly consumes to determine whether it may summarize, extract, or generate from the underlying data. Because the labels are honored inside the Microsoft 365 ecosystem, they provide the granular, per-item control needed to govern AI responses. This is the correct answer as it establishes classification at the source.

Enabling Microsoft Entra B2B collaboration is the correct approach because it lets external partners authenticate with their own home tenant credentials while the application is configured to accept tokens from those partner tenants. A B2B guest object is created in your directory for authorization, but no full user object or local credential exists, keeping your tenant clean and reducing password management. This supports true federation, single sign-on, and lifecycle management via the partner's identity provider. The application can use tenant allowlists to trust tokens from specific partner tenants, aligning with zero-trust principles.

Subject Rights Requests in Microsoft Priva is the automated workflow that locates, retrieves, and packages personal data stored across Microsoft 365 services to fulfill data subject requests such as access, export, and deletion. It uses data profiles and content search to identify relevant records, then facilitates review in a centralized case management experience, making it the correct module for managing subject rights requests.

Implementing automatic secret rotation using Key Vault with Event Grid and Azure Functions uses an event-driven model: Key Vault emits SecretNearExpiry events to Event Grid when a secret approaches expiration, and Event Grid triggers an Azure Function to generate a new secret version and store it back in the vault. This approach reacts in near real-time to actual secret lifecycle states, avoids manual scheduling, and is serverless and scalable, requiring no custom infrastructure. It automatically keeps secrets fresh, reduces the risk of expiration-related service outages, and eliminates the need for human-initiated rotation scripts.

Microsoft Sentinel automation rules and playbooks are the correct choice because Sentinel is a cloud-native SIEM/SOAR that centrally ingests security signals across the enterprise, including endpoints, and can trigger automated responses. Automation rules automatically run playbooks, which are built on Azure Logic Apps, to perform actions such as isolating a compromised device, blocking indicators, notifying security teams, and opening tickets. These playbooks can integrate with Microsoft Defender for Endpoint and other EDR solutions, making them a flexible and comprehensive way to automate response to common incidents.

It places Azure Front Door with WAF at the edge for global DDoS protection and web application firewall, followed by Azure Application Gateway with WAF for regional WAF inspection before the backend. This layered approach provides comprehensive security.

Defender for Office 365 blocks phishing emails at the mail gateway using threat intelligence and safe attachments/links. Conditional Access with session risk enforces least-privilege access based on real-time risk, while Purview DLP and sensitivity labels protect data across workloads. Sentinel integrates these signals and uses automation rules and playbooks for rapid, automated incident response, fulfilling all stated requirements. This layered approach covers email security, identity, data protection, and security operations.

Network Security Groups (NSGs) are a stateful packet-filtering service that evaluates allow/deny rules — based on source/destination IP, port, and protocol — against traffic flowing between subnets, VMs, or NICs in a virtual network. By default, NSGs include built-in rules that allow all internal VNet traffic and deny inbound internet, and they can be overridden with custom rules for granular segmentation. Because NSGs can be assigned to a subnet or NIC directly and incur no extra cost, they are the appropriate service for isolating subnets and controlling traffic between them.

Azure Virtual WAN with a secured virtual hub allows you to associate spoke virtual networks and use routing intent to automatically route traffic through the firewall. This eliminates the need for manual UDRs on each spoke, providing a centralized and scalable solution that meets the requirement of minimal complexity.

The Microsoft Defender for Cloud connector is the native data connector that directly imports security alerts and recommendations from Defender for Cloud into Sentinel via its API. This connector populates the SecurityAlert table with structured findings, including severity, status, and associated entities, enabling correlation with other data sources and automated SOAR actions. It is the only connector from the options that is purpose-built for this integration.

Microsoft Defender XDR is the correct choice because it is a true XDR solution that unifies detection, investigation, and response across endpoints, email, identities, applications, and data. It natively collects signals from Microsoft Defender for Endpoint, Office 365, Microsoft Defender for Identity, and Microsoft Defender for Cloud Apps, and combines them into a single incident view with automated self-healing actions. This enables security teams to detect and respond to sophisticated multi-stage attacks across the entire attack surface, which is exactly the goal of an XDR architecture.

A device compliance policy with a minimum OS version rule is correct because Intune evaluates the installed OS version against this rule during each compliance check. If the device falls below the threshold, it is marked non-compliant, which can trigger conditional access blocks or end-user remediation prompts. This rule directly enforces that devices remain on a supported OS version as a condition of accessing organizational resources.

Microsoft Defender for Identity is a cloud-based security solution that monitors on-premises Active Directory and cloud identities, generating signals for identity-based attacks such as pass-the-hash, Kerberoasting, and lateral movement. Its telemetry, including user behavior, logon events, and group policy modifications, is ingested by Microsoft Defender XDR to correlate and enrich incident detection with the identity context that is often central to attacks.

A Conditional Access policy can include all cloud apps in the 'target resources' assignment and then exclude the legacy application from the same assignment, allowing you to require MFA for every other cloud app. When the finance department is included in the users/groups, they will be prompted for MFA unless the sign-in targets the excluded legacy app, which precisely matches the stated requirement. Conditional Access policies are evaluated at sign-in time and provide the granular, app-level scoping that the other options lack.

An automation rule can be set to trigger when a Sentinel incident is created, and its action can call a playbook. The playbook, a Logic App, can use the Exchange Online connector to block the sender, disable the account, or quarantine the email, depending on the response logic. Because automation rules fire immediately on incident creation, this option provides the desired automated response to the phishing event. This is the designated mechanism for incident-driven orchestration in Sentinel.

Microsoft Authenticator with phone sign-in enables passwordless authentication for users by allowing them to sign in with their mobile device using biometrics or PIN. It works across applications and platforms, integrates with Microsoft Entra ID, and supports phishing-resistant methods, directly reducing credential theft risk and eliminating passwords.

An auto-labeling policy for sensitivity labels in Microsoft Purview lets you define rules that automatically inspect documents and emails for sensitive content (e.g., sensitive info types, patterns, or trainable classifiers) and apply the appropriate sensitivity label without user intervention. These policies run in simulation mode initially to gauge accuracy, then can be enforced in production to assign the label, enforce encryption, and trigger subsequent DLP. This is the only option that directly and automatically classifies content at scale, meeting the stated goal.

Microsoft Purview is the correct choice because it is Microsoft's unified data governance and compliance platform, providing automated scanning, classification, and labeling of data assets across cloud and on-premises sources. It includes the Data Map, Data Catalog, and Data Estate Insights to give a central inventory, track lineage, and enforce sensitivity labels via Microsoft Information Protection, which aligns directly with the company's data governance requirement.

While EventID 4625 captures Windows failed logon attempts, it does not include all authentication failure scenarios, such as Kerberos pre-authentication failures (EventID 4771), credential validation failures (EventID 4776), or failures from non-Windows sources like Azure AD sign-in logs. Additionally, certain failure conditions may generate different event IDs depending on the logon type or protocol, so a detection rule based solely on 4625 will have blind spots for those authentication failures.

Azure Monitor Agent (AMA) is the correct modern agent for Microsoft Sentinel because it unifies data collection across the entire Azure Monitor platform. It uses data collection rules (DCRs) to define exactly which data sources to collect, enabling granular filtering, multi-homing to multiple workspaces, and support for both Windows and Linux without the overhead of separate agents. AMA is the only forward-looking agent that Microsoft is actively investing in, with rich features like network isolation, Azure Arc support, and the ability to handle all log types Sentinel consumes.

Enabling Azure DDoS Protection on the virtual network is a foundational network security layer because it continuously monitors and mitigates volumetric, protocol, and resource-layer DDoS attacks at the Azure edge, using always-on traffic profiling and adaptive tuning to protect all public IP resources within the VNet. It provides both infrastructure-level (L3/L4) protection at no extra cost and the Standard tier with additional mitigation policies, telemetry, and cost protection. This directly aligns with defense-in-depth as the outermost perimeter defense for network availability, complementing but not replacing internal controls.

This is the correct combination because each service maps to a distinct requirement: Always Encrypted protects sensitive columns cryptographically so database administrators and compromised servers cannot read plaintext; Dynamic Data Masking limits unauthorized display of sensitive data; Azure SQL auditing sends fine-grained query and security logs to Log Analytics for centralized monitoring; and TDE with a customer-managed key in Azure Key Vault gives you control over encryption keys for at-rest protection, including rotation and revocation. Together they form a layered defense without conflicting overrides, and all are native to Azure SQL Managed Instance.

Dynamic Data Masking (DDM) is a database-level security feature that obfuscates sensitive columns in query results for non-privileged users. When a user lacks the UNMASK permission, Azure SQL Database rewrites the data on the fly so that values appear masked (e.g., '123-45-6789' becomes 'XXX-XX-6789') without altering the underlying stored data. This masking is applied at query time, which means the raw data remains intact in the database, and privileged users with the UNMASK permission see the original values. DDM is ideal for hiding data from application users or junior DBAs while keeping the data physically unchanged.

Prevents unauthorized sharing of personal data.

Microsoft Sentinel is the correct answer because it is a scalable, cloud-native SIEM and SOAR service that ingests logs from a wide range of sources, including Microsoft 365, Azure, third-party apps, and on-premises systems. It uses Kusto Query Language (KQL) for advanced hunting and custom analytics, and it provides built-in connectors for many security products. Sentinel centralizes security data, triggers alerts based on correlation rules, and supports automated response playbooks for end-to-end incident management.

This option correctly maps each requirement to the right Azure service: Conditional Access policies enforce MFA for all users and sign-ins, Intune compliance policies verify device health for mobile access, and Azure Bastion provides secure RDP/SSH to VMs through the Azure portal with built-in audit logging. For the database, enabling Transparent Data Encryption (TDE) encrypts data at rest, while enforcing TLS protects data in transit, together satisfying the encryption requirements. Notably, Bastion eliminates the need to expose VMs to a public IP or VPN, and its session logs provide the required audit trail.

Azure Firewall is a stateful, cloud-native firewall as a service that can be deployed in a hub VNet to centralize and enforce network security policies. It supports forced tunneling to route all internet-bound traffic (including traffic from on-premises via ExpressRoute/VPN) through the firewall, where it can inspect, filter, and log every session using application rules, network rules, and threat intelligence. Its built-in logging—via diagnostics, Azure Monitor, and Firewall Insights—provides the full traffic visibility required for a zero trust strategy.

The Microsoft Defender XDR connector brings Microsoft Defender for Endpoint's DeviceInfo table into Sentinel, including fields such as RiskScore and ExposureLevel. Running a Scheduled query rule on that connector lets you use KQL to filter where DeviceRiskScore equals 'High', map entities, and create an incident. This is the supported pattern because scheduled rules allow complex joins, longer time ranges, and robust entity mapping—essential for turning a live risk score into a reliable security alert.

Devices must be registered to be evaluated.

To meet a bring-your-own-key (BYOK) requirement on Azure Cosmos DB, you must configure a customer-managed key in Azure Key Vault and associate it with the Cosmos DB account. This uses envelope encryption where the Key Vault key wraps the account's data encryption keys, allowing you to independently rotate, revoke, or audit key usage. You can establish this by assigning a key URI from Key Vault to the Cosmos DB account (typically via a managed identity and appropriate Key Vault access policy), which gives you control over at-rest encryption.

Security defaults in Microsoft Entra ID are a preset group of identity security policies that automatically enforce MFA, require administrators to authenticate with MFA, and block legacy authentication. This is a best practice because it provides a robust baseline security posture out-of-the-box, drastically reducing account compromise risk without requiring per-user configuration or Premium licensing. For organizations that lack the licensing for Conditional Access, security defaults are the recommended way to ensure consistent enforcement of strong authentication across all users.

This is the correct behavior. The 'mark as spam' action sets the message's SCL to 6, which is the threshold used by Exchange Online to route the email to the recipient's Junk Email folder (depending on the mailbox's safe sender settings). It does not delete or reject the email; instead, it delivers it to the spam quarantine location within the mailbox, allowing the user to review it later.