Practice Free SC-200 Exam Online Questions

Explanation:

Internal threat: Modify the access policy settings for the key vault.

External threat: Modify the Key Vault firewall settings.

For internal threats involving a potential compromise of Fabrikam’s own Azure AD applications, the most direct and least disruptive remediation is to modify the Key Vault access policies (or RBAC assignments, if RBAC for Key Vault data-plane is in use) to immediately remove or reduce the compromised service principal’s permissions (Get/List/Decrypt/Sign/Wrap). Microsoft guidance for Key Vault access emphasizes least privilege and promptly revoking credentials or app permissions when compromise is suspected. Access policies (or data-plane RBAC) govern which identities can access secrets, keys, and certificates; adjusting these stops further data-plane actions by the compromised app. “Resource locks” protect against deletion or configuration changes at the management plane, but they do not remove a compromised identity’s ability to read or use vault objects, so they are not an appropriate first response for this scenario.

For external threats, Microsoft recommends hardening Key Vault firewall and networking: restrict public network access, allow only required IPs, use virtual network rules, and prefer private endpoints. Key Vault includes a built-in firewall for IP and VNet ACLs; tuning these controls reduces exposure to the public internet and blocks unauthorized traffic. NSGs apply to IaaS subnets/nics and don’t directly secure the public Key Vault endpoint. Azure Firewall can add perimeter control, but it is not necessary for remediating a specific Key Vault Defender alert; the most effective and immediate remediation is tightening the Key Vault firewall settings to limit external access pathways.

Explanation:

To collect event logs from Linux virtual machines in Microsoft Sentinel, the data ingestion path must be correctly configured through Azure Monitor (Log Analytics) and Sentinel connectors.

The correct order of actions is as follows:

1️ ⃣ Add Microsoft Sentinel to a workspace:

Sentinel requires a Log Analytics workspace as its data foundation. You must first enable Microsoft Sentinel on a workspace by selecting Microsoft Sentinel → Add → Select workspace. This step prepares the workspace to receive and analyze security data.

2️ ⃣ Add a Syslog connector to the workspace:

Linux systems send event data through Syslog. You must enable the Syslog connector within the Sentinel workspace. The connector defines which Syslog facilities and severities should be collected and ingested into Sentinel. It acts as the integration bridge between the Linux hosts and Sentinel’s analytics engine.

3️ ⃣ Install the Log Analytics agent for Linux on the virtual machines:

To forward the logs, each Linux virtual machine needs the Log Analytics agent (OMS agent). This agent collects the configured Syslog and performance data and sends it to the connected Log Analytics workspace.

This sequence ensures proper setup for Linux log ingestion: Sentinel is first activated, then the Syslog data source is configured, and finally, agents are deployed to gather and transmit the logs.

Explanation:

To collect event logs from Linux virtual machines in Microsoft Sentinel, the data ingestion path must be correctly configured through Azure Monitor (Log Analytics) and Sentinel connectors.

The correct order of actions is as follows:

1️ ⃣ Add Microsoft Sentinel to a workspace:

Sentinel requires a Log Analytics workspace as its data foundation. You must first enable Microsoft Sentinel on a workspace by selecting Microsoft Sentinel → Add → Select workspace. This step prepares the workspace to receive and analyze security data.

2️ ⃣ Add a Syslog connector to the workspace:

Linux systems send event data through Syslog. You must enable the Syslog connector within the Sentinel workspace. The connector defines which Syslog facilities and severities should be collected and ingested into Sentinel. It acts as the integration bridge between the Linux hosts and Sentinel’s analytics engine.

3️ ⃣ Install the Log Analytics agent for Linux on the virtual machines:

To forward the logs, each Linux virtual machine needs the Log Analytics agent (OMS agent). This agent collects the configured Syslog and performance data and sends it to the connected Log Analytics workspace.

This sequence ensures proper setup for Linux log ingestion: Sentinel is first activated, then the Syslog data source is configured, and finally, agents are deployed to gather and transmit the logs.

Explanation:

When you create a Microsoft Sentinel workbook that visualizes data retrieved using a Kusto Query Language (KQL) query, the workbook must use a data source that supports log analytics queries. According to Microsoft Sentinel and Azure Monitor documentation, Logs (Analytics) is the correct data source type for querying tables stored within a Log Analytics workspace, such as the Security Incident table. This table is where Microsoft Sentinel stores incident data.

In the workbook configuration, the Resource type determines which service the query context applies to. Since you are querying Microsoft Sentinel incidents (not general Azure Monitor logs or metrics), you must set the resource type to Microsoft Sentinel. This ensures that the workbook is connected to Sentinel’s analytics schema and can display visualizations (charts, metrics, timelines) based on Sentinel’s native data tables.

Alternative resource types such as Log Analytics or Workspace could technically access the same data, but Microsoft Sentinel documentation recommends selecting Microsoft Sentinel when the workbook is designed for security operations and incident analysis. This provides tighter integration with the SOC dashboard experience, Sentinel permissions, and security insights views.

✅ Therefore, the correct selections are: Data source: Logs (Analytics)

Resource type: Microsoft Sentinel

Explanation:

In Azure Security Center (now Microsoft Defender for Cloud), different roles have different levels of permission. To meet the principle of least privilege, you must assign only the minimal role required for each action.

Enable and disable Azure Defender

Enabling or disabling Microsoft Defender plans (formerly Azure Defender) changes billing and protection settings at the subscription level.

According to Microsoft documentation:

“Only users with the Subscription Owner or Security Admin roles at the subscription level can enable or disable Microsoft Defender plans.”

Because this change affects billing and overall subscription configuration, the Subscription Owner role is the appropriate one ― it has full control at the subscription scope.

Apply security recommendations to a resource

Applying recommendations (such as enabling disk encryption or updating system patches) involves managing configuration settings on specific resources.

The Resource Group Owner role provides full management access to all resources within that resource group, which includes the ability to implement or remediate recommendations.

Microsoft Defender for Cloud guidance states:

“To apply recommendations or perform remediation tasks on specific resources, the user must have write permissions on those resources ― typically provided by the Resource Group Owner or Contributor role.”

✅ Final Correct Mapping:

Enable and disable Azure Defender → Subscription Owner

Apply security recommendations to a resource → Resource Group Owner

Explanation:

To validate that Microsoft Defender for Cloud will trigger an alert when a malicious file is present on an Azure virtual machine running Windows Server, you should perform the following three actions in sequence:

Copy an executable file on a virtual machine and rename the file as ASC_AlertTest_662jfi039N.exe

Run the executable file and specify the appropriate arguments

Enable Microsoft Defender for Cloud’s enhanced security features for the subscription.

These actions will simulate a malicious activity on the virtual machine and generate an alert in Defender for Cloud. You can then verify the alert details and response recommendations in the Azure portal. For more information, see Alert validation – Microsoft Defender for Cloud.

Explanation:

Dropdown/Step Value to Select

where ResponseStatusCode in (…) ("204")

split([dropdown], "/")[-3] RequestUri

To detect Microsoft Graph operations that change role membership, you target POST requests to the directoryRoles … /members/$ref endpoint. Adding a member to a role via Microsoft Graph is performed with POST /directoryRoles/{role-id}/members/$ref and, on success, Graph returns HTTP 204 No Content. Therefore, filtering ResponseStatusCode to 204 isolates successful role-assignment events while excluding errors like 401/403 and non-mutating redirects such as 302.

The RequestUri contains the role identifier in the path. For URIs like:

https://graph.microsoft.com/v1.0/directoryRoles/{role-id}/members/$ref

splitting on “/” yields: [https:, , graph.microsoft.com, v1.0, directoryRoles, {role-id}, members, $ref]. The element at index -3 is the {role-id}. Hence, extend Role = tostring(split(RequestUri, "/")[-3]) correctly extracts the role GUID for reporting.

Putting it together, a concise query is:

MicrosoftGraphActivityLogs

| where RequestUri has_all ("https://graph.microsoft.com/", "/directoryRoles", "members/$ref") | where RequestMethod == "POST"

| where ResponseStatusCode in ("204")

| extend Role = tostring(split(RequestUri, "/")[-3])

| project TimeGenerated, IPAddress, ResponseStatusCode, Role

This returns the timestamp, source IP, success code, and the affected role ID for each successful role-membership addition in your tenant.