SC-100 Flashcards — Free Microsoft Cybersecurity Architect Study Cards

Configure an automation rule to run a playbook automatically

Automation rules in Microsoft Sentinel allow you to define automated responses that trigger when an incident is created or updated, including running playbooks (Azure Logic Apps workflows) automatically. This is the correct approach for automatically responding to high-severity incidents because it eliminates manual intervention and ensures consistent, immediate action based on incident properties like severity.

Create a DLP policy that detects and blocks credit card numbers in Exchange Online

Microsoft Purview Data Loss Prevention (DLP) policies can be configured to detect sensitive data types, such as credit card numbers, in Exchange Online emails. When a DLP policy is created with a rule that identifies credit card numbers and blocks the email from being sent, it directly prevents users from sharing that data via email. This is the native mechanism for enforcing DLP on email traffic in Microsoft 365.

Connect AWS and GCP accounts to Defender for Cloud and use Azure Policy to enforce the Microsoft Cloud Security Benchmark

Microsoft Defender for Cloud's multi-cloud CSPM capabilities allow you to connect AWS and GCP accounts directly, and then apply Azure Policy to enforce the Microsoft Cloud Security Benchmark (MCSB) across all connected clouds. This ensures a unified security baseline assessment for Azure, AWS, and GCP resources, as MCSB is the default policy initiative in Defender for Cloud.

Create a Conditional Access policy that requires compliant device

A Conditional Access policy in Microsoft Entra ID (formerly Azure AD) can enforce the requirement that only devices marked as compliant by Intune can access corporate email. This policy evaluates the device compliance status at authentication time and blocks or grants access based on that signal, ensuring that only managed and compliant devices can connect to services like Exchange Online.

Microsoft Authenticator app with passwordless sign-in

The Microsoft Authenticator app with passwordless sign-in is the correct primary method because it leverages the user's smartphone to provide a seamless, phishing-resistant authentication experience using public/private key cryptography (FIDO2/WebAuthn). This method aligns with the organization's goal of eliminating passwords while utilizing existing smartphone hardware, and it supports a simple user experience by requiring only a biometric or PIN verification on the phone.

Microsoft Entra ID Conditional Access

Microsoft Entra ID Conditional Access is the correct solution because it enables you to enforce access policies based on real-time risk signals, such as user risk, sign-in risk, and device compliance. It integrates with Identity Protection to evaluate dynamic risk levels and can block or require multi-factor authentication (MFA) accordingly, directly supporting the zero-trust principle of 'never trust, always verify'.

The policy condition requires a managed disk, but the VMs might have unmanaged disks.

The policy condition uses `field` to check for `Microsoft.Compute/virtualMachines/storageProfile.osDisk.managedDisk.id`, which requires the VM to have a managed disk. If the VMs use unmanaged disks (i.e., the `managedDisk` property is absent), the condition evaluates to false, and the `auditIfNotExists` effect never triggers the existence check for the Azure Security extension.

Scheduled query rule

A scheduled query rule is the correct choice because it allows you to define a KQL query that checks for user account creation events (e.g., from the SecurityEvent or AuditLogs table) and then use the query scheduling settings to run the query at a specific interval. You can then add a condition in the rule logic to filter for events occurring outside business hours (e.g., using the `datetime_part` function to check the hour of the event). When the query returns results, Sentinel automatically generates an incident for investigation.

Store the secret in Azure Key Vault and use a Key Vault reference in App Service.

Storing the client secret in Azure Key Vault and referencing it from App Service via a Key Vault reference is the most secure method. Key Vault provides centralized secret management, access control via Entra ID, auditing, rotation capabilities, and hardware-backed protection (HSM) for keys. App Service can resolve Key Vault references at runtime using its managed identity, so the secret never appears in application settings or code.

Microsoft Purview Data Map

Microsoft Purview Data Map is the correct choice because it is the foundational service that performs automated scanning, data discovery, and classification of data sources such as Azure Blob Storage, populating the catalog with sensitivity labels and classifications. It uses scan rule sets and classification rules to detect sensitive data types across registered sources. Azure Policy is a governance service for enforcing resource compliance, not for scanning and classifying data content. Microsoft Purview Information Protection applies sensitivity labels to files and emails but does not itself scan and classify data at rest in Blob Storage. Microsoft Purview Data Loss Prevention enforces policies to prevent data exfiltration, not to discover and classify stored data.

Configure a sensitivity label with encryption and watermark settings.

Sensitivity labels in Microsoft Purview Information Protection can be configured with encryption and content marking (watermark) settings, which are applied automatically when users apply the label. Option A is incorrect: the Azure Information Protection scanner discovers and labels existing files but does not configure label settings; the label itself must be defined. Option B is incorrect: a DLP policy can block sharing but cannot add watermarks or encrypt content on its own. Option D is incorrect: Microsoft 365 Message Encryption provides encryption for email transport but does not apply watermarks or enforce labels.

Windows Security Events via AMA

Windows Security Events via AMA is the correct choice because lateral movement from compromised on-premises servers to Azure VMs is detected through Windows security event telemetry such as logon events (4624, 4625), explicit credential use (4648), and special privilege assignment (4672), which this connector collects from both on-premises and Azure Windows machines into Microsoft Sentinel. The Azure Monitor Agent (AMA) with the Windows Security Events data connector supports the hybrid, multi-cloud scope described, making it the priority connector for this detection scenario. Syslog via AMA is not appropriate because Syslog captures Linux/network appliance messages, not the Windows authentication events needed to trace lateral movement. Office 365 Logs cover cloud productivity audit activity, and Azure Activity Log records control-plane operations on Azure resources, neither of which provides the host-level Windows logon telemetry required here.

Connect AWS and GCP accounts using the cloud connectors in Defender for Cloud

Connect AWS and GCP accounts using the cloud connectors in Defender for Cloud. Defender for Cloud's native multi-cloud support requires onboarding non-Azure environments through the AWS and GCP connectors, which establish the necessary trust and inventory so that resources, recommendations, and alerts from those clouds become visible in the portal. Only after this connection can Defender plans, compliance policies, or agent-based extensions be applied to those resources. Option A is premature because enabling subscription-level Defender plans only affects Azure resources, not AWS or GCP. Option C is a later configuration step that depends on data already being collected, and Option D is not the onboarding mechanism for multi-cloud visibility, since Azure Arc is used for connecting specific servers rather than enabling cloud-wide AWS/GCP visibility.

Denies creation of network security rules that allow traffic to ports other than 22 and 3389

The correct option is D: the policy denies creation of network security rules that allow traffic to ports other than 22 and 3389. Azure Policy definitions with a deny effect evaluate the properties of a resource being deployed—here, the destinationPortRange of a network security rule—and block the deployment when the condition is met, so rules permitting any port outside 22 and 3389 are rejected. Option A is wrong because the policy does not require ports to fall within a range; it blocks rules that allow ports other than the two specified. Option B is wrong because the policy targets NSG rule definitions in Azure Resource Manager, not live inbound traffic flows. Option C is wrong because the policy does not permit or allow traffic; it only denies noncompliant rule creation.

Add a virtual network rule for the specific VNet

The correct answer is A: Add a virtual network rule for the specific VNet. In Azure Storage, network access restrictions are configured on the storage account's Networking blade, where you can add virtual network rules that allow access only from selected VNets and subnets; this directly satisfies the requirement that 'seccorpstorage' be accessible only from a specific Azure virtual network. Option B is incomplete because enabling the Microsoft.Storage service endpoint on the subnet is a prerequisite that makes the subnet eligible, but the storage account still needs the corresponding virtual network rule to actually restrict access. Option C is wrong because an IP-based firewall rule uses public IP addresses and does not restrict access to a specific VNet's private traffic. Option D is wrong because enabling public network access opens the account to public connectivity rather than limiting it to one VNet.

AppLocker

AppLocker (option D) is the correct choice because it is the Windows feature that lets administrators define and enforce rules specifying which applications users can run on managed devices, and it can be configured and deployed through Intune via an application control policy. This directly satisfies the requirement that only approved applications execute on corporate Windows 10 devices. Windows Defender Firewall (A) controls network traffic by port, protocol, and address, not which local applications are permitted to launch. BitLocker (B) provides full-disk encryption for data-at-rest protection and has no application execution control. Windows Information Protection (C) is designed to separate and protect corporate data from personal data, not to whitelist approved applications for execution.