SC-100 Practice Questions

Applying Zero Trust principles to sensitive Operational Technology (OT) and IoT environments requires methodologies that do not disrupt critical operations. The Microsoft Cybersecurity Reference Architectures (MCRA) advocate for a phased approach starting with visibility.

Passive traffic monitoring is the foundational methodology for OT/IoT security. It allows for the discovery, inventory, and baselining of device behavior without sending any traffic to the devices, thereby eliminating the risk of disruption. This visibility is the first step in understanding the environment to apply Zero Trust controls.

Threat monitoring is a continuous process that uses the data gathered from passive monitoring to detect anomalous behavior, unauthorized communications, and known threats. This aligns with the Zero Trust principle of "assume breach" by constantly verifying network activity against expected behavior.

B. active scanning: This method is intrusive and can cause legacy or sensitive OT/IoT devices to malfunction or crash, directly contradicting the requirement to minimize the risk of disrupting business operations.

D. software patching: While essential for security hygiene, patching in OT environments is often a high-risk, complex process that requires significant downtime and vendor validation. It is not a primary methodology for minimizing disruption; rather, it's a carefully planned activity, often deferred in favor of compensating controls like monitoring and segmentation.

1. Microsoft Cybersecurity Reference Architectures (MCRA): In the "Operational Technology (OT) security" section (slide 43 in the November 2022 update)

the architecture diagram explicitly centers on "Passive (agentless) monitoring" as the primary mechanism for "Asset discovery

" "Vulnerability management

" and "Threat monitoring." It lists "Active scanning" as optional and potentially disruptive.

2. Microsoft Learn

"Microsoft Defender for IoT architecture": This document states

"The Defender for IoT network sensor connects to a SPAN port or network TAP and immediately begins collecting OT/IoT network traffic using passive (agentless) monitoring. The sensor has no physical or logical impact on the network..." This confirms passive monitoring is the core

non-disruptive technology.

3. Microsoft Learn

"Zero Trust for IoT security": This guidance outlines a strategy that includes "Configure security monitoring and threat detection." It emphasizes

"Continuous monitoring of devices is a critical component of a Zero Trust architecture... Use an agentless network monitoring solution to gain visibility into these previously unmonitored networks without impacting OT performance." This directly supports both passive and threat monitoring.

4. Microsoft Learn

"Device discovery with Microsoft Defender for IoT": This document details the discovery methods

stating

"Defender for IoT uses passive methods to discover devices in your network... Passive discovery methods support full visibility for your assets with zero impact on your network." This reinforces the non-disruptive nature of passive monitoring as a best practice.

To prevent a single compromised administrator account from deleting backups, the Microsoft Security Best Practice is to implement a separation of duties for critical operations. Multi-user authorization (MUA) using Resource Guard in Azure Backup is designed for this exact purpose. It ensures that destructive actions, such as deleting backups or reducing retention, require approval from a separate administrator who has permissions on the Resource Guard, which is typically managed by a different team. This prevents a single point of compromise from leading to data loss and is a core component of a ransomware recovery strategy.

A. The security PIN adds an extra authentication step, but it does not enforce separation of duties. A compromised administrator who has access to the Azure portal could still perform the destructive action.

C. Registering MABS with a Recovery Services vault is a standard configuration step required for backups to function; it does not provide any specific security protection against malicious deletion.

D. PIM provides just-in-time (JIT) access, which limits the time an account has elevated privileges. However, once the role is activated by the compromised user, they would have full permission to delete backups.

1. Microsoft Learn

"Multi-user authorization for Azure Backup using Resource Guard

" Section: "About Multi-user authorization for Backup." This document states

"Multi-user authorization (MUA) for Azure Backup allows you to add an additional layer of protection to critical operations on your Recovery Services vaults... This provides maximum security for your backups

ensuring that even in a scenario of a rogue administrator

critical operations can be performed only after getting the required authorizations."

2. Microsoft Learn

"Backup and restore plan to protect against ransomware

" Section: "Protect backups from attacks." This best practice guide explicitly recommends MUA: "To provide an additional layer of security before executing critical operations

Azure Backup provides multi-user authorization (MUA)... We highly recommend you enable MUA to provide enhanced protection for your backups."

3. Microsoft Learn

"Security features to help protect hybrid backups from attacks

" Section: "Preventing attacks." This document lists both MUA and the security PIN as features. However

MUA with Resource Guard is presented as the more robust solution for preventing malicious actions by enforcing authorization from a separate principal.

4. Microsoft Learn

"What is Privileged Identity Management?

" Section: "What does it do?". This document explains that PIM's purpose is to provide time-based and approval-based role activation to mitigate risks of excessive permissions

but it does not prevent an authorized (or compromised but activated) user from performing actions allowed by their role.

Microsoft Information Protection (MIP), part of the Microsoft Purview suite, is the solution designed to discover, classify, and protect sensitive data. A core feature of MIP is the use of sensitivity labels. These labels can be configured to apply protection settings and content markings, including watermarks, headers, and footers, to documents and emails. When a file or email is identified as containing sensitive data (either manually by a user or automatically based on policy), the appropriate sensitivity label is applied, which in turn adds the configured watermark. This directly fulfills the requirement of the scenario.

A. Microsoft Defender for Cloud Apps: This is a Cloud Access Security Broker (CASB) focused on monitoring and controlling data flow and threats within cloud applications, not directly applying content markings.

B. insider risk management: This solution correlates user activity signals to detect and manage potential internal risks; it does not apply watermarks to content.

D. Azure Purview: While Microsoft Information Protection is now part of the broader Microsoft Purview data governance platform, "Azure Purview" historically referred to the data cataloging and mapping service. MIP is the specific component that handles content marking.

1. Microsoft Learn. "Apply content marking with sensitivity labels." Microsoft Purview documentation. Under the section "What content markings can be applied

" it explicitly states: "When you apply a sensitivity label to a document or email

you can add headers

footers

and watermarks to the content."

2. Microsoft Learn. "Learn about sensitivity labels." Microsoft Purview documentation. In the introductory section

it lists the capabilities of sensitivity labels: "After a sensitivity label is applied to content

any configured protection settings for that label are enforced on the content. You can configure a sensitivity label to apply... Content markings (such as headers

footers

or watermarks)."

3. Microsoft Learn. "What is Defender for Cloud Apps?". Microsoft Defender for Cloud Apps documentation. This document describes the service as a CASB that provides visibility and control over cloud apps

confirming its primary purpose is different from content marking.

4. Microsoft Learn. "Learn about insider risk management." Microsoft Purview documentation. This source details the solution's focus on detecting

investigating

and acting on risky user activities

which is distinct from applying protection features like watermarks to documents.

The Microsoft Cloud Adoption Framework's DevSecOps best practices strongly advocate for eliminating secrets from CI/CD pipelines to reduce the attack surface. Managed identities provide an automatically managed identity in Azure Active Directory (Azure AD) for services like Azure DevOps. When used with a service connection configured for Workload Identity Federation, it allows the pipeline to authenticate to Azure resources without storing any passwords, client secrets, or certificates in Azure DevOps. This secret-less approach is the most secure and recommended method for service-to-service authentication, directly aligning with modern DevSecOps principles.

A. Using an Azure AD user account with a password, even in Key Vault, introduces a manageable secret that must be rotated and can be compromised. Best practice is to eliminate secrets entirely.

B. Group managed service accounts (gMSAs) are an on-premises Active Directory Domain Services (AD DS) identity type and are not designed for authenticating cloud services like Azure DevOps to Azure.

C. Azure AD Privileged Identity Management (PIM) is designed for just-in-time (JIT) access for human users, often requiring interactive approval or MFA, making it unsuitable for automated, non-interactive CI/CD pipelines.

---

1. Microsoft Cloud Adoption Framework

DevSecOps controls

"Secure the pipeline" section: "Use service principals that have the minimum permissions required. Rotate secrets and certificates regularly. Better yet

use managed identities to remove the need for secrets and certificates." This directly recommends managed identities over secret-based methods.

Source: Microsoft Learn

learn.microsoft.com/en-us/azure/cloud-adoption-framework/secure/devsecops-controls#secure-the-pipeline

2. Azure DevOps Documentation

"Connect to Microsoft Azure by using an ARM service connection": This document describes the "Workload Identity federation" authentication method for service connections

stating

"Workload identity federation allows you to create a secret-free service connection in Azure Pipelines to Azure." This is the modern implementation that leverages managed identities or other workload identities.

Source: Microsoft Learn

learn.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure?view=azure-devops#create-an-azure-resource-manager-service-connection-using-workload-identity-federation

3. Azure Active Directory Documentation

"What are managed identities for Azure resources?": "Managed identities for Azure resources is a feature of Azure Active Directory... You can use the identity to authenticate to any service that supports Azure AD authentication

without having any credentials in your code." This explains the fundamental benefit and purpose of managed identities

which is to eliminate credentials.

Source: Microsoft Learn

learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview

The Azure Security Benchmark v3 control "Secure management ports" (related to control LT-4: Limit network access to management ports) is designed to mitigate threats by limiting the exposure of management interfaces like RDP and SSH. Microsoft Defender for Cloud's primary recommendation to satisfy this control is to enable just-in-time (JIT) VM access. JIT access works by locking down inbound traffic to these ports by default using Network Security Group (NSG) rules. Access is granted only upon request, for a limited time, from approved IP addresses. Implementing this configuration directly remediates the identified risk, thus increasing the security score for the "Secure management ports" control.

B. No: This is incorrect. The proposed solution directly addresses the core requirement of the "Secure management ports" control. Enabling JIT VM access is the specific, recommended action by Microsoft to remediate this finding and improve the associated security score.

1. Microsoft Learn

"Azure Security Benchmark v3 control LT-4: Limit network access to management ports". Under the "Azure Guidance" section

it explicitly states: "Use Microsoft Defender for Cloud's just-in-time (JIT) VM access feature to request access to the VM. You can use JIT to lock down the inbound traffic to your VMs

reducing exposure to attacks while providing easy access to connect to VMs when needed."

2. Microsoft Learn

"Security controls and their recommendations". This document lists "Secure management ports" as a security control. The recommendations associated with this control include "Management ports of virtual machines should be protected with just-in-time network access control

" which directly validates the proposed solution.

3. Microsoft Learn

"Understanding just-in-time (JIT) VM access". This document details the feature

explaining: "When you enable just-in-time VM access

Defender for Cloud creates network security group (NSG) rules which restrict access to management ports so they can't be targeted by attackers." This confirms its function in securing management ports.

The proposed solution is incorrect. Relying on IP address restrictions for Azure Front Door's backend is not a secure or reliable method. The backend IP addresses for the Front Door service are dynamic and shared among many customers. Using the AzureFrontDoor.Backend service tag in an access restriction rule would allow traffic from any Front Door instance, not just your specific instance.

The correct and recommended method is to configure the App Service to validate the X-Azure-FDID HTTP header. This header contains the unique ID of your specific Front Door instance, ensuring that the App Service only accepts traffic that has been routed through it. An even more secure alternative is to use Azure Private Link to connect Front Door Premium to the App Service, removing public internet access to the origin entirely.

A. Yes: This is incorrect because using IP-based restrictions is not a reliable or secure method to lock down access to a specific Front Door instance, as the IP ranges are shared and subject to change.

1. Microsoft Learn. (2023). Secure traffic to Azure App Service. "The IP address range for Front Door's backends might change... We don't recommend using IP address restriction rules for this purpose. Instead

we recommend that you use service tag-based rules or use the X-Azure-FDID header."

2. Microsoft Learn. (2023). Restrict access to a specific Azure Front Door instance. "To lock down your application to accept traffic only from your specific Front Door instance

you should filter based on the X-Azure-FDID HTTP header that Front Door sends... You can configure this in your origin web server to restrict traffic based on the value of this header."

3. Microsoft Learn. (2023). Use Private Link with Azure Front Door Premium. "By using the Private Link feature

you can secure your origins in Azure Front Door Premium... When you use Private Link

traffic between Azure Front Door and your application traverses over the Microsoft backbone network

eliminating exposure from the public internet."

The solution must satisfy two distinct encryption key management requirements.

1. Insurance Claim Files: The requirement is for encryption keys to be "hosted on-premises." Azure Blob storage with customer-provided keys (CPK) meets this. With CPK, the client application provides the encryption key with each read/write request. Azure Storage uses the key for the operation but never stores it. This allows the key to be securely stored and managed in an on-premises Hardware Security Module (HSM).

2. Cardholder Data: The requirement is for "encryption keys managed by the company." Storing cardholder data in an Azure SQL Database encrypted with Transparent Data Encryption (TDE) using keys from an Azure Key Vault Managed HSM fulfills this. A Managed HSM provides a single-tenant, FIPS 140-2 Level 3 validated HSM where the company retains full and exclusive control over the key lifecycle, satisfying the "company-managed" requirement.

C. Azure Key Vault Managed HSM is a cloud service hosted in Azure, not on-premises. This configuration violates the requirement for insurance claim file keys to be hosted on-premises.

D. Microsoft-managed keys are created, stored, and managed by Microsoft, not the company. This configuration violates the requirement for cardholder data keys to be company-managed.

1. Customer-Provided Keys (for Answer A): Microsoft Learn. (2023). Provide an encryption key on a request to Blob storage. "When a client application presents an encryption key on the request

Azure Storage performs encryption and decryption transparently... The encryption key is not persisted in Azure Storage." This supports using keys managed entirely outside of Azure

such as on-premises.

2. TDE with Managed HSM (for Answer B): Microsoft Learn. (2024). Customer-managed transparent data encryption (TDE) - Azure SQL Database & Azure Synapse. "Customer-managed TDE... provides control over key lifecycle management... Azure Key Vault Managed HSM is a highly available and scalable single-tenant solution for managing cryptographic keys." This confirms it as a company-managed key solution.

3. Managed HSM Location (for why C is incorrect): Microsoft Learn. (2023). What is Azure Key Vault Managed HSM?. "Azure Key Vault Managed HSM is a fully managed

highly available

single-tenant

standards-compliant cloud service..." This clarifies that the service is not hosted on-premises.

4. Microsoft-Managed Keys (for why D is incorrect): Microsoft Learn. (2023). Azure Storage encryption for data at rest. "By default

all data in a storage account is encrypted using Microsoft-managed keys. With Microsoft-managed keys

Microsoft creates and manages the keys that are used to encrypt your data..." This shows the company does not manage these keys.

The recommendations provided by Microsoft Defender for Cloud are based on security policies. Azure Policy is the native Azure service for creating, assigning, and managing these policies to enforce rules and effects over resources. To mitigate the identified risks, you would use Azure Policy to create and assign policies that mandate the recommended configurations, such as requiring private link connections or disallowing public access for storage accounts. Defender for Cloud leverages Azure Policy as its underlying engine to monitor for configuration drift and assess compliance, making Azure Policy the direct tool for remediation and enforcement.

A. Azure Storage Analytics provides logging and metrics for monitoring storage account performance and usage, not for enforcing security configurations.

B. Azure Network Watcher is a suite of tools for monitoring and diagnosing network health and performance; it does not enforce resource-level security policies.

C. Microsoft Sentinel is a Security Information and Event Management (SIEM) solution used for threat detection and response, not for proactive configuration enforcement.

1. Microsoft Learn

"Security policies in Microsoft Defender for Cloud": This document states

"Microsoft Defender for Cloud uses Azure Policy to set its security policies... When you enable Defender for Cloud

the security policy built-in to Defender for Cloud is reflected in Azure Policy as a built-in initiative". This establishes the direct link between Defender for Cloud's recommendations and Azure Policy as the enforcement mechanism. (Reference Section: "What are security policies

initiatives

and recommendations?")

2. Microsoft Learn

"What is Azure Policy?": This documentation explains that "Azure Policy is a service in Azure that you use to create

assign

and manage policies. These policies enforce different rules and effects over your resources

so those resources stay compliant with your corporate standards and service level agreements." This confirms its role in enforcing the types of rules mentioned in the question. (Reference Section: "Overview")

3. Microsoft Learn

"Azure Policy built-in definitions for Azure Storage": This page lists specific

pre-built policies that directly correspond to the recommendations in the question

such as "Storage accounts should use private link connections" (Policy ID: 64040326-0fa3-4624-81ae-3ba3c369a988) and "Storage accounts should restrict network access" (Policy ID: 34c877ad-507e-4c82-993e-3452a6e0ad3c). This demonstrates that Azure Policy is the designated tool for implementing these specific controls.

The core requirements are automation to minimize manual intervention and the ability to perform a specific response action (posting to Microsoft Teams), which are the defining characteristics of a Security Orchestration, Automation, and Response (SOAR) strategy. In Microsoft Sentinel, SOAR capabilities are implemented using playbooks. Playbooks are automated workflows built on Azure Logic Apps that can be triggered by security alerts. They execute a predefined set of actions, such as creating a ticket, blocking an IP address, or, as required in the scenario, posting a message to a Microsoft Teams channel. This directly addresses both minimizing manual effort and integrating with Teams for notifications.

A. data connectors: These are used exclusively for ingesting data and logs from various sources into Microsoft Sentinel; they do not perform any automated response actions.

C. workbooks: These are interactive visualization tools and dashboards for analyzing and reporting on the data within Microsoft Sentinel, not for orchestrating automated responses.

D. KQL: Kusto Query Language is used to write analytics rules for threat detection and to perform threat hunting queries, but it is not the mechanism for automating the response to a detected threat.

1. Microsoft Azure Documentation

Microsoft Sentinel

"Automate threat response with playbooks in Microsoft Sentinel": "A playbook is a collection of procedures that can be run from Microsoft Sentinel in response to an alert. A playbook can help automate and orchestrate your threat response... Playbooks in Microsoft Sentinel are based on workflows built in Azure Logic Apps". This document explicitly identifies playbooks as the tool for SOAR.

2. Microsoft Azure Documentation

Microsoft Sentinel

"Tutorial: Use playbooks to respond to threats in Microsoft Sentinel": This tutorial provides a step-by-step guide on creating a playbook that

upon receiving an alert

"sends a message to your security operations channel in Microsoft Teams or Slack to make sure your security analysts are aware of the incident." This directly confirms playbooks meet the specific requirement of the question.

3. Microsoft Azure Documentation

Microsoft Sentinel

"Connect data sources": "To onboard Microsoft Sentinel

you first need to connect your data sources." This reference clarifies the singular role of data connectors as an ingestion mechanism

distinct from response automation.

4. Microsoft Azure Documentation

Microsoft Sentinel

"Visualize and monitor your data": "After you connected your data sources to Microsoft Sentinel

you can visualize and monitor the data using the Microsoft Sentinel adoption of Azure Monitor Workbooks". This confirms that workbooks are for visualization

not automation.

A post-breach response plan for a compromised computer, especially in a ransomware scenario, must prioritize containment to prevent lateral movement. The Microsoft Detection and Response Team (DART) methodology emphasizes this containment phase. Machine isolation is a core response capability in Microsoft Defender for Endpoint designed for this purpose. It disconnects the compromised device from the network, effectively stopping the threat from spreading to other resources. The isolated machine maintains a connection only to the Defender for Endpoint service, allowing security teams to conduct investigations and remediation actions safely without risk of further network contamination. This is the most direct and effective immediate response action for a compromised endpoint.

A. controlled folder access: This is a preventative Attack Surface Reduction (ASR) control configured before an attack to protect specific folders, not a post-breach response action.

B. application isolation: This is less comprehensive than machine isolation. An attacker may have compromised the entire operating system, making application-level isolation insufficient for containment.

C. memory scanning: This is a detection method used by security tools to find threats, not a response or containment action taken after a compromise is confirmed.

E. user isolation: This action, such as disabling an account, is appropriate for a compromised identity, not for containing a threat on a compromised computer itself.

1. Microsoft Learn. "Take response actions on a device in Microsoft Defender for Endpoint." Under the section Isolate devices from the network

it states

"This action can help prevent the attacker from controlling the compromised device and performing other activities such as data exfiltration and lateral movement." This directly supports machine isolation as a primary post-breach response.

2. Microsoft Security Blog. "The Microsoft DART ransomware approach and best practices." In the article

under the Contain phase of the incident response lifecycle

a key recommended activity is to "Isolate compromised systems: Disconnect affected systems from the network to prevent further spread." This aligns the answer directly with the DART approach mentioned in the question.

3. Microsoft Learn. "SC-100: Design solutions for security operations." In the module covering incident response with Microsoft Sentinel and Microsoft Defender XDR

containment actions are a key topic. The documentation emphasizes using built-in tool capabilities

such as device isolation in Defender for Endpoint

to contain threats during an active incident.